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ABSTRACT 


This thesis is a case study that examines missile development and integration for the 
DDG-1000 program. In particular, it analyzes various programmatic decisions through 
the lens of systems engineering standards, articles in scholarly journals, established 
government acquisition guidelines, and case studies of government and commercial 
engineering projects. Four risks were identified. First, failure to establish top-level 
requirements that reflect DDG-1000 specific needs introduces the potential for the 
missiles to fail performance or safety evaluations. Second, late requirement changes 
imposed by the government increase the potential for costly rework and schedule delays 
if integration issues surface during testing. Third, a “use as is” decision (meaning that 
legacy missile requirements were applied to the DDG-1000 missile effort) could result in 
an inadequate system architecture and/or late identification of system incompatibilities. 
Finally, organizational and funding issues have hampered the establishment and 
efficiency of engineering change control and integration management. The thesis 
recommends: that DOD acquisitions continue to emphasize and enable rigorous 
application of systems engineering early in the acquisitions process; that all programs 
perform a thorough flow-down of requirements even if utilizing legacy systems; and that 
all funding for weapon development be placed in the control of the Program Executive 
Office for Integrated Warfare Systems. 
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EXECUTIVE SUMMARY 


This thesis is a case study that examined missile development and integration for the 
DDG-1000 program. It describes the strategic situation that spurred the initial DDG-1000 
concept and how the program has changed in size and scope over time. It also describes 
combat system development for the ship, particularly the Dual Band Radar and the Joint 
Universal Weapon Link (JUWL), which allows SM-2 and ESSM missiles to be employed 
by the class. It analyzed various DDG-1000 programmatic decisions through the lens of 
systems engineering standards, articles in scholarly journals, established government 
acquisition guidelines, and case studies of government and commercial engineering 
projects. 

DDG-1000 was an outgrowth of the “Revolution in Military Affairs” (RMA) 
philosophy that gained prominence immediately following the First Gulf War. The RMA 
specifically advocated developing and fielding the most technologically advanced 
systems possible so that U.S. and allied forces could gain overwhelming dominance on 
the battlefield. Developing multiple such technologies and installing them simultaneously 
into a new ship class runs counter to the mindset that guided previous ship and submarine 
advancements. Historically, new combatants utilized “tried and true” technologies in 
most areas while featuring two or three significant improvements. Hence risk to the new 
class was limited. The commonality of hull, mechanical and electrical and combat 
systems (C/S) between the DD-963, FFG-7, CG-47, and DDG-51 class are an example of 
this approach. When successful systems were introduced and operationally tested (such 
as gas turbine propulsion), they were incorporated into future classes. Similarly, C/S 
advancements could be retro-fitted into previous classes (such as CG-47 vertical launch 
systems were retro-fitted into the DD-963 class). 

Conversely, the Navy had experienced substantial problems in developing 
multiple advanced technologies for the Seawolf class submarine. The costs of the effort 
were so substantial, in fact, that Congress truncated the program. The Air Force’s B-2 
bomber program encountered similar problems and met a similar fate. Nevertheless, 
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DDG-1000 proceeded with this risky development strategy. The results were much the 
same as the B-2 and Seawolf. 

Missile development for DDG-1000 took the opposite approach. “Legacy” 
missiles were designated for incorporation into DDG-1000 under the assumption that 
minimal modifications to the missiles would be necessary. But this decision may prove to 
be a mistake because the radar and combat systems that will be used to employ the 
missiles are completely new and the legacy missiles may require significant changes to 
function with the new systems. The interfaces between the missile, the combat system, 
and the radar are critical to achieving desired performance. Because the ship, combat 
system, radar, and missile variants are still in development, it is not possible to give an 
unequivocal or complete analysis of their performance. However, we can analyze the 
effort in terms of risk and lessons learned from prior case studies. The analysis of missile 
development conducted for this thesis identified four main risks. 

First, failure to establish top level missile requirements that reflect DDG-1000 
specific needs introduced the potential for the missiles to fail perfonnance or safety 
evaluations. DDG-1000 has a different mission, different operating environment, and 
different threat set than the platforms the SM and ESSM were designed to protect. Failure 
to establish new requirements means that there will be no way to truly assess the 
performance of the missiles in comparison to their legacy version. 

Second, late requirement changes imposed by the government increased the 
potential for costly rework and schedule delays if integration issues surface during 
testing. The Navy originally directed the use of the SM-2 Block III-B missile for DDG- 
1000. In 2012, several years into the project, the III-B missile was replaced with the 
Block III-A version. The missiles are not identical and their performance differences 
have already prompted software changes in the radar and introduce additional risk that 
other differences will not be captured before operation testing. 

Third, a “use as is” decision regarding missile interfaces was made early in the 
development effort. In essence, the only new requirements given to the ESSM and SM 
missile design team related to the development of a new ship-to-missile weapon link on a 
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new frequency. All other requirements, such as pre- and post-launch interfaces, 
electromagnetic vulnerability requirements, and so on, were carried forward from the 
legacy Aegis variants of the missiles. This “use as is” decision could result in inadequate 
system architecture, late identification of system incompatibilities, or both. It is a 
certainty that the mechanical and electrical environment of DDG-1000 will differ from 
the DDG-51 and CG-47 classes-it only remains to be seen if the differences have adverse 
effects on missile perfonnance or safety. Late identification of such issues could result in 
costly and time consuming changes to missile, radar, or launcher design. 

Finally, organizational and funding issues have hampered the establishment and 
efficiency of engineering change control and integration management. These are critical 
efforts to support integration of the JUWL-equipped missiles with the new combat 
system, radar, and launcher. Delays in these processes make an already challenging 
development effort that much more difficult. 

The thesis recommends that DOD acquisitions continue to emphasize and enable 
rigorous application of system engineering principles early in the acquisitions process; 
that all programs perform a thorough flow-down of requirements even if utilizing legacy 
systems; and that all funding for weapon development be placed in the control of the 
Program Executive Office for Integrated Warfare Systems. All of these recommendations 
are based upon results from prior development efforts as well as systems engineering 
standards and best practices from academia, industry, and government. In particular, the 
critical importance of integration is supported by Langford’s Engineering Systems 
Integration: Theory, Metrics and Methods and Krygiel’s Behind the Wizard’s Curtain: 
An Integration Environment for a System of Systems (Langford 2012; Krygiel 1999). 

Finally, the thesis contends that consolidation of resources and control over 
systems engineering processes is supported by the historical success of the Aegis combat 
system and the Navy nuclear power program. Both efforts were afforded complete 
control over all aspects of their respective system designs, improvements, training, 
maintenance, and support. 
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I. 


INTRODUCTION 


A. BACKGROUND 

The Department of Defense (DOD) has found it increasingly difficult to develop 
and acquire advanced systems for military use that meet cost, schedule, and performance 
goals (Kadish 2005; Charette 2008). The problem will be even more challenging in the 
foreseeable future as defense budget levels are expected to remain stagnant for the next 
decade (Congressional Budget Office [CBO] 2013). 

The DOD has had a long struggle with efficient system development and both 
identified causes and potential solutions have been proposed for as long as the DOD has 
existed (Kadish 2005). The systems acquired are often based on extremely advanced 
technology, have extremely high performance standards, and are expected to operate in 
harsh environments. They are expected to have long service lives and to be very reliable, 
easy to maintain, and easy to repair. Systems are also increasingly expected to be 
interoperable with other new and legacy systems as the DOD continues to pursue its “net- 
centric” paradigm for weapons systems (Defense Acquisition University [DAU] 2010). 
All of these desired factors, but particularly the drive for ever-increasing performance, 
would naturally be expected to increase the anticipated cost and development time for the 
system. 

However, there is also an expectation of “affordability” for every system (Welby 
2013). Congress has cut or significantly curtailed programs that have extremely high per- 
unit cost compared to previous versions of similar systems, despite improved 
performance. For instance, final numbers of the B-2 “Stealth” bomber, the Seawolf class 
submarine, and the F-22 fighter programs were dramatically reduced after it became 
apparent that each would have an extremely high per-unit cost. There are certainly other 
factors that influenced Congressional decision-making on these programs, including 
perceived threats, schedule delays, and so forth, but cost is one of the primary lenses 
through which Congress examines programs (Rand Corporation 2011a). 
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One of the methods the DOD uses to attempt to save money in acquisition is the 
re-use of existing systems, sub-systems and components. The Zumwalt-class ship 
program, also known as the Guided Missile Destroyer-1000 or DDG-1000 program, was 
directed to use existing missiles in its design, thus sparing the expense of developing an 
all-new missile. This directive was believed to require minimal effort as the missiles 
would only need to be modified to operate with the new radar featured on DDG-1000. 
Therefore, integration activities and associated funding have been very limited in 
comparison to “new development” programs. Furthennore, the modification effort was 
not organized according to traditional development program guidelines but was instead 
pursued through a contractual modification to an existing engineering support contract. 
DDG-1000 is currently scheduled to begin operational test and evaluation (OT&E) 
activities in 2015 (O’Rourke 2013). 

B. PURPOSE 

The purpose of this paper is to examine the history of combat systems 
development in the DDG-1000 program, specifically the integration of legacy missiles 
with the new-development radars and combat system of DDG-1000, in order to evaluate 
the validity of published “best practices” as well as identify new lessons learned that can 
be utilized by future acquisition programs. 

C. RESEARCH QUESTIONS 

No DDG-1000 ships have been launched and no missiles have been fired from the 
ship. Therefore, it is problematic to discuss missile integration efforts in absolute terms of 
“success” or “failure.” However, the history of the DDG-1000 program and the missile 
integration effort in particular are long enough to allow them to be examined in relation 
to established government, industry, and academic standards. This thesis will address the 
following questions: What lessons can be learned from the integration of legacy missiles 
with the new-development combat systems of DDG-1000? Does missile integration on 
DDG-1000 validate or reject integration “best practices” as described in government 
policy documents, industry standards, and articles in scholarly journals? 
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D. BENEFITS 


It is hoped that the case study presented in this thesis will provide readers with a 
relevant analysis of “what works” when integrating legacy weapons systems into a new, 
complex platform. 

E. SCOPE AND METHODOLOGY 

This paper will address the integration of legacy missiles into the new- 
development combat systems of DDG-1000 via analysis following a literature review. 
The paper will address technical and programmatic decisions from the inception of the 
DDG-1000 program until now, and will identify potential future risks based on the 
historical analysis. Sources for the literature review include program artifacts such as 
acquisition milestone reviews, briefings, and risk assessments; government reports 
including Congressional testimony and Government Accountability Office documents; 
scholarly articles, textbooks, and theses on the topics of acquisition and integration; 
defense, acquisitions, and systems engineering professional journals; and DOD 
acquisition, engineering, and program management guidance documents. 
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II. HISTORY OF THE DDG-1000 PROGRAM 


A. INTRODUCTION 

The DDG-1000 has been one of the Navy’s most visible and controversial 
development projects for almost twenty years. This chapter will describe the strategic and 
operational context in which the program was initiated. It will describe the key 
operational and technical features of DDG-1000 and will highlight key events since the 
program’s start. This chapter will also describe the current state and potential future for 
DDG-1000, which is far different from its original announced purpose. 

B. GENESIS OF THE PROGRAM 

The DDG-1000 program began in 1994 (Hagerty et al. 2008). It was an outgrowth 
of the “Surface Combatant for the 21st Century (SC-21)” study the Navy conducted in 
the early 1990s (O’Rourke 2013). Originally known as DD-21, and then DD(X), it was 
planned as a significant class of 32 warships. It was part of a family of three future 
warship classes conceptualized to implement the Navy’s post-Cold War strategic vision. 
The three proposed ship classes were the DD(X), the CG(X), and the LCS. The new 
strategic vision, outlined in the Navy document Forward...From the Sea, reflected a 
change in emphasis from open ocean dominance against a peer adversary to power 
projection and influencing events ashore (Dalton 1994). The three ship classes reflected 
that shift. The DD(X) would provide precision strike against land targets, the CG(X) 
would provide advanced air and ballistic missile defense, and the LCS would provide 
surface and antisubmarine (ASW) capability in the littorals (CBO 2003). The Navy 
originally intended the new ship to replace the FFG-7 and eventually the DDG-51 class 
ships, at a per-unit cost less than that of the DDG-51 (Hagerty et al. 2008). 

The new strategy was based on the perceived lack of a near-peer adversary 
capable of challenging U.S. dominance on the open ocean. It also reflected a new belief 
that the technological dominance of U.S. forces (demonstrated during the First Gulf War) 
would allow the U.S. to fundamentally alter the nature of warfare. This “Revolution in 
Military Affairs” (RMA) paradigm dominated strategic thinking in the early to mid- 
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1990s and spurred a military acquisition philosophy that emphasized acquiring even more 
advanced technologies (Metz and Kievit 1995). During the 2000 presidential campaign, 
then-candidate George Bush gave speeches calling for the Pentagon to “skip a generation 
of weapons” in order to achieve overwhelming dominance against any potential 
adversary (Owens 2013). 

The 1993 Defense Bottom-Up Review (BUR; forerunner of the Quadrennial 
Defense Review) was explicit in describing how the U.S. would apply this technological 
superiority to defeating two simultaneous enemies in regional wars (Aspin 1993). The 
Middle East and Korean peninsula were specifically cited as potential hotspots, and 
significant discussion was given to potential “dangers to democracy and reform” in the 
former Soviet Union and Eastern Bloc (Aspin 1993, 2). 

These new systems would be combined into a “net-centric” architecture. This 
architecture, supported by equally advanced command and control systems, would give 
U.S. forces an overwhelming advantage against regional adversaries. The Navy “vision 
statement” SeaPower 21 described this architecture in naval terms (Clark 2002). While 
the RMA may have fallen from the front page of the strategic debate, it continues to 
shape military acquisition. Every major new weapon system is described in terms of its 
“net-centric” capabilities and its ability to operate in a joint environment (DAU 2011). 

DDG-1000 reflected the “generation after next” technology sought by the Navy 
and the RMA. The ships would feature advanced land attack capabilities, allowing them 
to take the place of the recently retired Iowa-class battleships. The ships would not only 
launch Tomahawk missiles but were also to feature an advanced gun system firing 
extended range projectiles to perfonn naval surface fire support (NSFS) missions. They 
would also have low-observable characteristics facilitating their operation in littoral 
areas. They were to feature a host of other technological improvements allowing for 
expansion of capabilities as even newer technologies became available. For instance, the 
ship’s integrated power system was envisioned as powering lasers, rail guns, or other 
emerging technologies. Finally, the ships were to utilize the “reduced manning” concept, 
automating previously manpower-intensive functions and thus costing less to operate 

than traditional warships (Liszniansky 2006). 
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There were a total of ten critical technologies (see Figure 1. ) identified in the 
DDG-1000 program (Government Accountability Office 2004): 

• Wave-piercing tumblehome hull design 

• Advanced Gun System (AGS) and Long-Range Land Attack Projectile 
(LRLAP) 

• Integrated Composite Deckhouse and Apertures 

• Total Ship Computing Environment (TSCE) 

• Dual Band Radar (DBR) 

• Integrated Undersea Warfare System (IUWS) 

• Peripheral Vertical Launch System (PVLS) 

• MK 57 Vertical Launch System (VLS) 

• Automatic Fire Suppression System (AFSS) 

• Integrated Power System (IPS) 


Transforming Warfighting: DDG 1000 Critical Technologies 


Infrared Mockups (IR) 

• Land-based suppressor 
testing complete 

• At-sea panel testing 
complete 

Dual Band Radar (DBR) 
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Integrated Composite 
Deckhouse & Apertures (IDHA) 
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Advanced Gun System (AGS) 

• Initial guided flight testing complete 

• Land-based testing complete 


*- 






Peripheral Vertical Launch 
System (PVLS) / Advanced VLS 
• Two detonation 
tests conducted 
■ Missile restrained 
firing testing complete 



/ 

([>1 SMC flv-throuah 

| Hull Form Scale Model 

Integrated Undersea 
Warfare (IUSW) 

Autonomic Fire Suppression / 5 

System (AFSS) / 11 

Total Ship Computing 
Environment (TSCE) 

• Performance validated by 
model testing 

• At-sea weapons effect and ftv - k ¥V 

• At-sea mine avoidance 


testing demonstrated 


successfully coded, tested, and 
authorized by the Government 7 • 


testing complete 
1 Automation 
testing complete 


Figure 1. DDG-1000 Critical Technologies (from Liszniansky 2006) 
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This ambitious level of technological development in a single hull was precisely 
what was called for by the Navy’s strategic vision. However, it ran counter to established 
Navy shipbuilding policy that limited technological advances to two or three areas in a 
new ship design. The great success of the DDG-51 class can be attributed, at least in part, 
to the fact that it re-used almost every significant ship system featured on the CG-47 class 
cruiser. Re-use of those successful systems greatly lowered the technological risk of the 
program (Hagerty et al. 2008). 

C. EVOLUTION OF THE PROGRAM 

The program began in earnest in August of 1998 as the Pentagon awarded 
contracts to two different industry groups to begin work on system concept designs 
(Defense Industry Daily 2013). Work was performed throughout 1999, 2000, and 2001. 
The original acquisition plan included a “winner take all” decision to select a design 
submitted from two industry teams, headed by Bath Iron Works and Ingalls Shipbuilding. 
This unique approach had never been applied to a major shipbuilding program before 
(Office of the Assistant Secretary of Defense 2002). 

New threats began altering national priorities during the period of initial design 
work. Even before the terrorist attacks of September 11th, 2001, the Pentagon and new 
administration had been working to define a new strategic vision and a more flexible, 
adaptable military. The 2001 Quadrennial Defense Review (QDR) emphasized ballistic 
missile defense, threats from failed states and non-state actors, and the need to transform 
U.S. forces to defeat such “asymmetric” threats (Office of the Secretary of Defense 
(OSD) 2001). The RMA transfonnation was now presented as the way to defeat such 
asymmetric threats. The terrorist attacks of September 11th and the resulting occupation 
of Afghanistan and Iraq marked a return to low intensity and counter-insurgency warfare. 
These experiences seemed to validate the QDR’s emphasis on flexibility; this type of 
conflict was a far cry from the technologically driven force-on-force “Sea Strike” that 
had been anticipated in SeaPower 21. The need for a conventional surface vessel armed 
with lasers or rail guns seemed far down the list of priorities. By December of 2001, DD- 
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21 was officially cancelled. The reasons cited included rising cost estimates and lagging 
technological development (O’Rourke 2004). 

The DD-21 was immediately replaced with DD(X) (Defense Industry Daily (DID) 
2013). In April of 2002, Ingalls (now part of Northrop Grumman Ship Systems) won the 
“winner take all” design decision and was awarded a $2.8 billion contract for detailed 
design of their winning proposal (DID 2013). 

The Navy remained a strong proponent of the program, continuing to cite the need 
for the new destroyer. The procurement was reduced to 24 ships, however, at which time 
the planned CG(X) vessels would be ready for construction. Both Navy and CBO cost 
estimates continued to rise as technology development lagged behind schedule (Hagerty 
et al. 2008). 

By the time the Navy revised its 30-year shipbuilding plan and presented it to 
Congress in 2005, DD(X) had been reduced to “8-12” ships (Hagerty et al. 2008, 15). 
This was driven by the ever-increasing cost estimates for the ships, which in turn were 
driven by slow technological development. The CBO estimated that the lead ship would 
cost $3.3 billion and have life cycle costs nearly double that of the DDG-51 class (DID 
2013). Ironically, 2005 saw many of the critical technologies pass significant testing and 
readiness milestones, including the Total Ship Computing Environment (TSCE), the Dual 
Band Radar (DBR), the hull fonn, and the Peripheral Vertical Launch System (PVLS). 
The ship also passed its initial flag-level Critical Design Review (CDR) in September of 
2005. The perception of yet another over budget and behind schedule program was firmly 
entrenched in Congress, however, and scrutiny of the program continued. 

In April of 2006, the Navy announced a new plan for procuring seven DDG-1000 
ships and the FY2007 budget authorized construction of the first two vessels (O’Rourke 
2008). The Navy had also continued to alter its fundamental strategic vision to include 
homeland defense, cooperation with international partners, and provision of humanitarian 
assistance (Roughead 2007). The specific mention of homeland defense signified the 
increasing importance of sea-based ballistic missile defense. And although the 
Cooperative Strategy for 21 st Century Seapower retained the concepts of forward 
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presence and dominance in regional war, the new emphasis on engagement and “low- 
level” operations continued to widen the gulf between the new, large and expensive 
DDG-1000 and the Navy’s self-professed needs. The evolving vision was much more in 
line with the second of the three SC-21 vessels, the Littoral Combat Ship (LCS) (a 
program which has had its own share of problems). DDG-1000 was also out of 
consideration for performing the existing BMD mission (which fell to BMD-capable 
Aegis platforms) and the future BMD mission (which were to be fulfilled by CG(X)). 

The Navy’s justification for continuing the DDG-1000 stated that it would serve 
as a technological bridge to CG(X). The Navy also claimed that DDG-1000 would not 
only be able to perform its original mission of littoral fire support but that it was also 
fully capable of conducting the blue water, fleet support missions of the DDG-51. This 
line of reasoning may have backfired as the argument opened the DDG-1000 up for direct 
comparison directly to the DDG-51 in terms of cost, performance, sea-keeping, and a 
host of other factors. The appropriateness of such a comparison continues to be a source 
of debate (Miller 2012). 

Cost estimates and criticism on Capitol Hill continued to rise in 2007 and 2008. 
Navy estimates at per ship cost had risen to $3.3 billion each and some outside sources 
estimated $5 billion or more (Hagerty et al. 2008). Even with the most optimistic 
estimates, DDG-1000 was shaping up to be the most expensive non-nuclear surface 
vessel the Navy had ever bought. Skepticism concerning some of the ten critical 
technologies also became pronounced, including serious discussion about the stability of 
the new hull design and the capability of the ship to perform area air defense and open- 
ocean ASW (DID 2013). In 2007 and 2008, Congress began openly challenging the 
Navy’s shipbuilding plans and there were repeated calls to restart DDG-51 production, 
which had ended in 2005 (DID 2013). 

In July of 2008, Chief of Naval Operations (CNO) Gary Roughead testified 

before Congress that the Navy wanted to limit production of DDG-1000 to just two ships 

and re-start the DDG-51 production line in order to meet its future surface combatant 

needs (Hagerty et al. 2008). This plan also entailed cancellation of the CG(X) program. 

The first five re-started DDG-51 hulls would be Flight IIA types; production would then 
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shift to a Flight III design which would be developed to meet the BMD mission. This 
complete reversal in policy was a shocking turnaround given how strongly Navy 
leadership had defended the program in the past. The reasons for this change were 
numerous but are perhaps best captured in these two statements by the CNO: 

While there are cost savings associated with the DDG 1000's smaller 
crew, they are largely offset by higher estimated maintenance costs for this 
significantly more complex ship. Clearly the relative value of the DDG 
1000 resides in the combat system (Dual-Band Radar, Volume Search 
Radar, ASW Suite, etc.) that provide this ship with superior warfighting 
capability in the littoral. However, the DDG 51 can provide Ballistic 
Missile Defense capability against short and medium range ballistic 
missiles and area Anti-Air Warfare capability (required in an anti-access 
environment) where the DDG 1000 currently does not. Upgrading the 
DDG 1000 combat system with this capability would incur additional cost. 

The DDG 51 class also possesses better capability in active open ocean 
anti-Submarine Warfare than does the DDG 1000. On balance, the 
procurement cost of a single DDG 51 is significantly less than that of a 
DDG 1000, and the life-cycle costs of the two classes are similar. 
(Roughead, quoted in DID 2013) 

I started looking at the DDG-1000. It has a lot of technology, but it cannot 
perform broader, integrated air and missile defense... Submarines can get 
very close [due to design compromises], and it does not have the ability to 
take on that threat... And I look at the world and I see proliferation of 
missiles, I see proliferation of submarines. And that is what we have to 
deal with. (Roughead, quoted in DID 2013) 

A third DDG-1000 was eventually authorized in the FY2009 Defense Budget 
Authorization, although the Navy was given the ability to transfer the funding 
($2.5 billion) to DDG-51 construction if it chose to do so. The third DDG-1000 was 
primarily a Congressional move to support the shipyards in Bath, Maine, and Pascagoula, 
Mississippi. 

The decision to end the DDG-1000 program after three ships obviously had 
significant consequences. First, the decision resulted in a Nunn-McCurdy breach for the 
program, formally reported to Congress in April 2010. The Nunn-McCurdy provisions 
were first included in the 1982 Defense Budget Authorization Act and were subsequently 
enacted into the U.S. code (Rand Corporation 2011). They call for any defense 
acquisition program to be reviewed or presumptively cancelled if the program exceeds 
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cost estimates by certain percentages. In order to avoid the presumptive cancellation, the 
acquisition authority for the program must provide certification of certain criteria for the 
program to Congress. These criteria include: 

• The program is essential for national security 

• No alternatives will provide an acceptable capability to meet requirements 
and that new estimated of PAUC and APUC have been determined to be 
reasonable by CAPE 

• The program has a higher priority than the programs whose funding must 
be reduced to accommodate the “breaching” program 

• The management structure of the program is adequate to manage and 
control PAUC or APUC (Rand Corporation 2011, 20) 

The provisions examine two basic measures of program cost. PAUC is the total 
development and procurement cost divided by the number of items procured. APUC is 
the total procurement cost divided by the number of items procured. The triggers 
associated with Nunn-McCurdy are summarized in Table 1. : 


Table 1. Nunn-McCurdy Provisions (from Rand Corporation 2011, 15) 


Breach Type 

Measure examined 

Baseline 

Trigger Level 


PAUC 

Current 

> 15% 

Significant 

APUC 

Current 

> 15% 

PAUC 

Original 

> 30% 


APUC 

Original 

> 30% 


PAUC 

Current 

> 25% 

Critical 

APUC 

Current 

> 25% 

PAUC 

Original 

> 50% 


APUC 

Original 

> 50% 


The reduced quantity of ships resulted in a new PAUC of $5.8 billion, up from 
$3.1 billion that had been estimated at the 2005 program baseline. A root cause analysis 
was completed by the Office of the Secretary of Defense’s (OSD) Performance 
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Assessments & Root Cause Analysis (PARCA) office to determine reasons for the 
overrun. The main driver was, as expected, the reduction in quantity of ships. PAUC and 
APUC are very sensitive to quantity fluctuations. However, PARCA also identified other 
factors contributing to DDG-lOOO’s enormous cost growth. The results are summarized 
in Table 2. : 


Table 2. DDG-1000 Cost Growth Root Causes (from Rand Corporation 2011, 25) 


Acquisition phase/activity 

Cost growth root cause 

Baseline determination 

Unrealistic estimate 

Immature technology; excessive manufacturing and 
integration risk 

Unrealistic performance expectations 

Program execution 

Changes in procurement quantity 

Funding instability 

Unanticipated technical issues 


The PARCA analysis, much like a 2009 GAO report, highlighted continuing 
concerns about technology maturity on some of the ship’s critical systems. It warned that 
since the first hull had just begin construction, and many of the technologies would not be 
certified until after installation, the program was accepting a high risk of potential re¬ 
work or even design changes. In particular, the GAO cited the TSCE and the VSR radar 
as “immature” and several years behind schedule (GAO 2009). 

In June of 2010, the Navy announced that the VSR portion of the DBR would be 
removed from the ship design (DID 2013). The removal of VSR was a cost/benefit 
decision, saving approximately $100 million for each hull. It also required modifications 
to the MFR radar, allowing it to perform some search functions. The decision was also 
influenced by the development of the AMDR, the next generation ballistic missile 
defense radar which was intended for the future Flight III DDG-51 (Miller 2012). Rising 
costs and limited space on the DDG-51 hull for the new AMDR meant that “retro-fitting” 
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AMDR into the DDG-1000, as well as the possibility of increasing the DDG-1000 
procurement and modifying it into the next generation of BMD ship (instead of building 
DDG-51 Flight III), became real possibilities. These issues will be discussed in greater 
detail in Chapter III on combat systems development. 

Finally, the Navy recently began investigating the potential of using regular steel, 
instead of advanced composites, to construct the deckhouse for DDG-1002 (Fabey 2013). 
This is another cost saving move which the Navy claims will not affect the “stealth” 
characteristics of the ship. The composite materials have been a challenge for both 
shipyards involved in DDG-1000 construction. 

D. CURRENT STATUS 

The DDG-1000 program is no longer the centerpiece of the future Navy. The 
original procurement of 32 ships has been reduced to just three. A program once touted as 
the future of the Navy is now essentially advertised as a test-bed for technologies that 
will be installed on other combatants (Miller 2012). Costs, as predicted by various 
agencies since the start of the program, have greatly exceeded estimates and are 
summarized in Table 3. : 


Table 3. DDG-1000 Cost Growth Summary (from GAO 2013, 55) 


Measure 

1998 Baseline 

Aug 2012 

% change 

Total ships 

32 

3 

- 90% 

Total cost 

$34.8 

$21.5 

- 38% 

Research & Development Cost 

$2.3 

$10.3 

+ 353% 

Procurement Cost 

$32.5 

$11.1 

- 65% 

Per ship cost: APUC 

$1.0 

$7.2 

+ 543% 

PAUC (without R&D) 

$1.0 

$3.7 

+ 248% 

Total acquisition time (in months) 

128 

222 

+ 73% 

all $ in billions 
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As of March 2013, DDG-lOOO’s hull is approximately 82% complete. DDG-1001 
is approximately 52% complete, and DDG-1002 has begun (Zumwalt Program Office 
2013). Most of the critical technologies will not have been demonstrated until after their 
installation in the hull, a point of technical risk that has been raised since 2004 (GAO 
2013). The program is placing a great deal of faith in its Engineering Development 
Model (EDM) risk mitigation strategy. The strategy calls for EDMs to be built and tested 
for all critical technologies so that significant issues can be discovered earlier in the 
design and development phase of the program. DDG-1000 is scheduled to be delivered to 
the Navy in 2014 with a significant OT&E period to follow. 

In considering the program as a whole, one can only conclude that the Navy has 
yet to learn the lessons of previous major acquisition programs. When per unit costs 
become excessive, Congress will simply balk at the expense, regardless of technological 
advances. The desire for technological advancement inevitably leads to schedule delays, 
which in turn means that the strategic and operational needs of the service may have 
changed in the interim. This affected DDG-1000 particularly hard, as the concept of a 
land-attack ship was new to the Navy anyway. 

The DDG-1000 now enters the same territory as the B-2 bomber, the F-22 fighter, 
and the Seawolf submarine: a platform with potentially enonnous capabilities that the 
nation has decided is too expensive to build and operate. While acknowledging the fact 
that rising DDG-51 Flight III costs may still allow the DDG-1000 to re-enter the 
conversation as a possible future BMD platform, the ship’s main legacy will likely hinge 
upon how many of her transformational technologies become mainstays for other ships. 
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III. DDG-1000 COMBAT SYSTEM DEVELOPMENT HISTORY 


A. INTRODUCTION 

One of the hallmarks of the DDG-1000 program has been the stated intent to 
develop and field the most cutting-edge technologies possible for naval warfare. 
Advanced technologies were to be implemented in every area of the ship, from the 
material used to build the deckhouse to the method of providing main propulsion. There 
were a total of ten critical technologies identified in the program (GAO 2013). Combat 
systems advancements were the leading features of the program, but challenges in 
developing these technologies have given rise to criticism of DDG-1000 for both 
effectiveness and cost-effectiveness (Miller 2012). This chapter will briefly outline the 
history of combat systems in the program. Primary attention will be given to the DBR 
because it is the primary item that must integrate with missiles, although the launcher will 
also be examined. 

B. THE ADVANCED GUN SYSTEM AND LONG-RANGE LAND ATTACK 

PROJECTILE 

In one sense, the Advanced Gun System (AGS) and Long-Range Land Attack 
Projectile (LRLAP) are the raison d’ etre for the entire DDG-1000 program. As 
described in Chapter II, precision land attack and Naval Surface Fire Support (NSFS) are 
the primary mission of the class. The advent of the Tomahawk cruise missile had made 
the surface Navy relevant again for strategic and pre-emptive strikes against enemy 
targets. However, the final retirement of the Iowa-class battleships in the mid-1990s 
meant that the Navy’s traditional role of providing tactical fire support to troops ashore 
was limited to the 5-inch guns of the DD-963, CG-47 and DDG-51 classes. Many in 
Navy and Marine circles felt the weapons were simply inadequate for the task, having 
limited range and firepower (Welch 2007). 

However, even with the relative deficiencies of current 5-inch guns compared to 
the Navy’s retired 8- and 16-inch guns, the benefits of naval gunfire for the NSFS 
mission are still pronounced. Ships can provide a constant volume of firepower in 
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contrast to air-delivered support (which has a cycle time). Gunfire is also vastly less 
expensive per shot than a cruise missile or air-delivered ordnance. 

The AGS system was intended to overcome the deficiencies of the Navy’s 5-inch 
gun system. It is a 6.1-inch (155mm) gun system with a fully-automated ammunition 
handling and loading system. It will meet extended range requirements by utilizing the 
rocket-assisted and precision-guided LRLAP round. It will also be capable of firing 
conventional (unguided) 155mm rounds (DID 2013). The weapon’s magazines will hold 
approximately 600 rounds (O’Rourke 2013). 

Technical risks and delays with the system have revolved primarily around the 
rounds themselves. The Extended Range Guided Munition (ERGM) program was a 
twelve-year, $600 million failed effort to develop an extended range round to be fired 
from the existing 5-inch/54 gun system (Matthews 2008). The primary challenge is 
developing internal guidance components that can withstand the shock of being fired 
from an artillery piece. LRLAP also had to redesign its rocket booster, although earlier 
tests had met range requirements. The program had a successful flight test of its 
redesigned round in early 2013 and contracts are now in place to install AGS in all three 
DDG-1000 hulls (DID 2013). Concerns about limited magazine capacities on the ships 
remain, but the AGS and LRLAP are expected to meet the requirements set for them. 
Whether or not those requirements meet the needs of the Navy will not be known until 
the ship is employed. 

C. MK57 VERTICAL LAUNCHER SYSTEM AND PERIPHERAL 

VERTICAL LAUNCH SYSTEM 

DDG-1000 features two improvements in missile launcher design when compared 
to the current mainstay of the Navy: the MK41 vertical launcher system (VLS) installed 
on the CG-47 and DDG-51 classes (and multiple allied ship classes). 

The first improvement is the MK57 launcher itself. The launcher’s cells are larger 
than the MK41, allowing it to carry all current VLS weapons and accommodate future 
weapons that could feature increases in length, weight, and diameter. It features an open 
architecture design, which should minimize the amount of modification required to 
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accommodate those future weapons. In particular, the canister electronic unit (CEU) will 
serve as an interchangeable interface between weapon and launcher, eliminating the need 
to otherwise permanently modify launcher hardware or software to accept a particular 
weapon. Thus, the system should meet the Navy’s desired “any missile, any cell” design 
(Raytheon 2013). The ship’s combat system would still need to be modified to ensure 
that it could communicate with the new weapon via the CEU. These modifications are 
presumed to be software adjustments only. Finally, the launcher’s gas management 
system is also designed to accommodate future weapons and their expected increases in 
rocket motor exhaust mass and flow rate (Raytheon 2013). 

The second innovation on DDG-1000 is the introduction of the peripheral vertical 
launch system (PVLS). Although sometimes confused in the literature with the Mk57 
launcher itself, the PVLS denotes the arrangement of the MK57s throughout DDG- 
1000’s hull and their protection by a new armored enclosure (DID 2013). There are 20 
groups of four missile cells each distributed outboard on the hull. The armored enclosures 
are designed to funnel explosive energy out and away from the ship’s hull during combat, 
thus protecting the internal spaces of the ship as well as adjacent launcher cells. The 
current Mk41 VLS is a single “bloc” of cells, centerline on the CG-47 and DDG-51. A 
single hit on the Mk41 in combat could cause the entire launcher to be inoperable, thus 
depriving the ship of its primary AAW armament. 

Like almost all new technologies on the DDG-1000, the Mk57/PVLS encountered 
some technical challenges and schedule delays. The new launcher has not, however, been 
a significant programmatic or technical risk to date (DID 2013). 

D. DUAL BAND RADAR 

1. Brief Description of Current Radars 

Before describing the development of the DBR for DDG-1000, it may be helpful 
to briefly review the operation of a typical microwave radar and highlight the 
characteristics of radar systems that use conventional antennas and those using phased 
arrays. 
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Figure 2. shows a generic microwave radar and its main components. 



Figure 2. Generic microwave radar (from Harney 2005, 87) 

In the most general sense, a radar system generates electromagnetic radiation and 
transmits it into the atmosphere. The radiation scatters when encountering objects; the 
scattered signal that returns to the radar antenna can be evaluated to detennine the 
bearing and range to the object. Repeated transmissions and returns can be analyzed to 
extrapolate the object’s speed and direction of travel (Naval Education and Training 
Command (NETC) 2000). 

All radars use some form of antenna to focus the transmitted signal in a certain 
direction of travel and into a certain beam fonn. It is by using this directionality and 
focus as a reference point (as well as known constants for signal speed) that the 
radar system assesses the returned signal to give useful information to the radar operator. 
A “traditional” microwave radar uses some form of a parabolic dish to focus the 
transmitted energy of the radar (see Figure 3. for common types). This dish is 
mechanically moved through the desired field of regard by a series of motors and 
gimbals. For instance, an air-search radar will typically spin 360 degrees to search the 
most volume of air space possible around the radar set itself. A monostatic radar uses the 
same antenna to transmit and receive the RF energy. A duplexer controls the timing and 
channeling of the sent and received signals so that there is no interference internal to the 
system. A bistatic radar uses a separate dish for sent and received signals. The two 

antennas are usually in close physical proximity to each other (Hamey 2005). 
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Figure 3. Common Reflective Antenna Shapes (from Skolnick 2008, 560) 

Variations in the characteristics of the radar (frequency/wavelength, amount of 
power generated by the radar, rate of antenna spin, etc.) result in performance 
differences. Those performance differences are maximized depending on the intended 
function of the radar. As mentioned, air search radars typically cover a 360 field and are 
designed to transmit energy into the widest area possible. They can have detection ranges 
in excess of 200 nautical miles (NETC 2000). A missile director, on the other hand, 
typically features a very narrow beam that is steered only the amount necessary to keep 
its target within the director’s beam. 

In the naval environment, radars have been optimized for surface detection and 
tracking, gunfire support, air search and tracking, missile guidance, and so on (NETC 
2000). Search and track radars are typically “pulsed” beam forms, meaning that the RF 
energy is emitted in pulses. During the non-transmitting period of time the radar receives 
and processes the return from the target. The more rapidly the radar “pulses” its signal the 
more rapidly it can update its target information. However, high pulse repetition rates 
(PRR) reduce the effective range of the radar. Illumination radars are often have 
extremely high PRR or are of the continuous wave type because intercepting a fast target 
requires the most accurate target position possible. Continuous wave illuminators utilize 
the frequency shift between its own signal and the target return signal (the Doppler shift) 
to determine target range, etc. They are often of the bistatic type-the NATO SeaSparrow 
missile system is a good example (NETC 2000). 
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It is important to note that missile engagement systems that utilize continuous 
wave illumination require the missile to have a receiver onboard the missile to receive the 
reflected energy from the target, a processor to calculate target position in relation to the 
missile’s own position, and an autopilot which will command the missile to maneuver to 
intercept the target. The illuminator uses the reflected energy to calculate a pointing 
position to maintain its beam on the target (NETC 2000). When used in an environment 
where targets are travelling at high subsonic or supersonic speeds and have a small radar 
cross-section, it becomes clear that these calculations and updates must be performed as 
rapidly as possible. 

While traditional antenna systems are a very capable and mature technology, they 
do have significant drawbacks. First, the mechanical systems required to allow the RF 
energy to be coupled into the moving antenna are complex and prone to failure (or are, at 
least, maintenance-intensive). Second, the varying characteristics needed for different 
applications are implemented primarily via the physical and mechanical characteristics of 
the radar; which meant that ships needed a multitude of independent radar systems to 
accomplish their varying missions. As mentioned, the frequency and pulse width of the 
radar, which greatly determine its range resolution, are fixed by its electronic and 
mechanical properties, as are its maximum effective range, performance against certain 
size targets, and so on (O’Donnell 2010; NETC 2000). 

Consider the DD-963 class destroyers, which entered the fleet in the mid-1970s. 
By the early 2000s, the ships had a wide variety of radar systems installed as listed in 
Table 4. . 


22 



Table 4. DD-963 class installed radars 


Radar 

Function 

SPS-40 

Air search 

SPS-55 

Surface search 

SPS-64 

Surface search 

Furuno 

Commercial surface search radar, 
used for navigation support 

SPG-60 

Air target fire control for MK86 
gunfire control system (5” guns) 

SPQ-9 

Surface target for control for MK86 
gunfire control system (5” guns) 

MK23 TAS (Target 
Acquisition System) 

Air search radar for the SeaSparrow 
weapon system 

MK95 

Fire control director for SeaSparrow 
weapon system 

MK15 Phalanx 

Two radars (search and track) to 
support the MK15 Phalanx CIWS 
(Close In Weapon System) 


Each of these systems requires maintenance and upkeep, specific training for both 
operation and maintenance, spare part support (which entails a logistic support system), 
and so on. The complexity of the systems removes the possibility of cross-training sailors 
to operate and maintain more than one system; indeed the Navy has multiple ratings of 
sailors to perform those functions. 

A phased-array radar introduces a new approach to implementing radar antenna 
functionality. The antenna is a flat panel of multiple emitting elements. The radar signal 
can be adjusted (via phase timing) so that each module emits its signal to produce a 
coherent radar beam in a desired direction (as seen in Figure 4. ). This greatly improves 
performance. It increases the speed with which the radar can scan its field of view and it 
eliminates the complex mechanical systems required for a moving antenna (NETC 2000). 
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The time required for a mechanically-scanned radar to move its field of view 20 degrees 
is measured in seconds. A phased array can perform the same re-direction in 
microseconds (O’Donnell 2010). This enonnous improvement, coupled with the power of 
modem computers to process returned signals, results in dramatic performance 
improvements. The radar can produce extremely accurate information about the contacts 
it is tracking. Recall the earlier discussion of the necessity of accurate information when 
attempting to accurately track and intercept high speed targets. 


Broadside Beam Scan To 30 deg 


Element 

Number ; 

N *7—^ WV j V -* 

4 •— c AAAA - > 

3 •—< A/yyK * 

2 7—^ VWK -* 

1 

Courtesy at MIT t«icoin Laboratory • 

Used witli Parnassian 

IEEE New Hampshire Section 
IEEE AES Society 

Figure 4. Formation of radar wave by phased array (from O’Donnell 2010, 8) 


The phased antenna also allows the radar to form multiple beams by selectively 
controlling the timing and phase of the elements, which in turn allows the radar to 
perform multiple functions simultaneously as shown in Figure 5. (O’Donnell 2010). All 
phased array antennas with a sufficient number of elements can perfonn multiple 
functions if the control software allows it; one must be cautious in interpreting the names 
and nomenclature of specific radar systems. For instance, the SPY-3 radar destined for 
DDG-1000 is commonly known as the Multi-Function Radar (MFR). Likewise Thales 
advertises its APAR as the first “true” multi-function radar despite Aegis’ operational 
history since 1983 (Thales 2013, Jane’s 2013). 
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Figure 5. SPY-1 Functions (from Lockheed Martin 2013) 


Because of limits on the amount of phase shift that can be applied to the emitted 
RF energy in a phased array, such systems typically feature three or four arrays spaced to 
ensure 360 degree coverage (White and Billups 2008). Other variations include a single 
array that is mechanically moved, creating a hybrid mechanical/phased antenna (Skolnick 
2008). 

Phased array radars are commonly referred to as either “active” or “passive.” The 
distinction lies primarily in how power is generated in the radar. “Passive” denotes that 
the individual modules in the antenna array receive their power from a common source as 
is the case in a traditional antenna setup (see Figure 6. ). This requires extensive 
“plumbing” to support the creation of the signal, transmission to the elements, and 
environmental controls for the entire arrangement. The space required for the hardware 
and its associated weight is one of the main considerations for shipboard implementation 
of this type of radar (Harney 2005). In particular, the necessity for extensive waveguide 
hardware results in loss of signal strength and potential for mechanical failure (Al-Rashid 
2009). This is not to say that traditional radars did not require extensive apparatus to 
operate; it is merely to point out that no improvement is without its limitations. As an 
example, the sea-based X-band radar (SBX) developed for the Missile Defense Agency 
(MDA) utilized a phased array antenna. The radar and its ancillary equipment are 
installed on a modified offshore oil drilling platfonn that is over 280 feet tall (Goldberg 
2006). The entire system weighs over 4 million pounds (Skolnick 2008). The ongoing 
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debate about the suitability of the DDG-1000 or the DDG-51 Flight III as a suitable host 
for the AMDR depends greatly upon the capacity of the hull to accommodate the radar 
and its ancillary equipment (O’Rourke 2012). 



Figure 6. Typical Passive Array Arrangement (from O’Donnell 2010, 50) 

SPY-1 is an S-band passive phased array radar (NETC 2000). The SPY-1 has 
4,350 elements per antenna array. The elements are subdivided in 32 “modules” or 
“subarrays” for transmission and 68 for receipt. This facilitates the division of power in 
the array (Jenn 2013). Aegis ships have four arrays positioned to provide 360 degree 
coverage. The Aegis system is far more than just the radar information processor-it is the 
heart of a multi-mission warfare command system (see Figure 7. ). In addition to the 
SPY-1 radar, the ships utilize the SPG-62 fire control radars for tenninal phase 
illumination of targets. The Aegis system processes the incoming radar information and 
allocates radar resources to continue conducting search, track, and missile uplink 
functions. It also transmits the target information to the missiles it launches and “cues” 
the SPG-62 radars to provide the required terminal phase illumination (Jane’s 2013). As 
seen in the diagram, the Aegis system utilizes other sensors beside the SPY-1; these can 
include other air and surface search radars. Use of these sensors provides two main 
benefits. First, the additional sensors may be optimized for performance in a certain area 
(for example, the SPS-49 is an extremely long-range air search radar) that can augment 
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SPY-l’s capabilities. Second, the additional sensors provide redundancy and provide the 
combat system decision system with additional resources to identify, evaluate, and 
process contacts. 



Figure 7. Block Diagram of Aegis System on DDG-51 (from Jane’s 2013) 


Active phased arrays, on the other hand, feature signal generation in each 
individual element or small subset of elements (Skolnik 2008). A typical arrangement is 
shown in Figure 8. This provides several significant benefits. It eliminates the need for 
extensive waveguides and reduces the signal loss between the signal generator and the 
transmitter (Al-Rashid 2009). It allows each element to function as a receiver, greatly 
increasing the number of data points available for the radar’s associated processors. It 
also allows the system to degrade “gracefully,” as the loss of an individual 
transmit/receive element has less impact on system performance than the loss of an entire 
“subarray” or the loss of the signal generator (Al-Rashid 2009). The active array retains 
all of the advantages of the phased array over the mechanical antenna. 
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Figure 8. Typical Active Array Arrangement (from O’Donnell 2010, 49) 


The Active Phased Array Radar (APAR) is an X-band active phased array radar 
currently in use by the Dutch and German navies (Thales 2013). It provides many of the 
same functions as Aegis, although it does not utilize dedicated terminal phase 
illumination radars. Instead, APAR itself provides terminal illumination by commanding 
certain T/R elements to illuminate the target at the final stage of the engagement. The 
APAR utilizes Interrupted Continuous Wave Illumination (ICWI), a variation of a 
continuous wave beam described earlier, to perform this task (Thales 2013). 

The APAR, like the SPY-1, is supported by other onboard sensors. The APAR 
radar is combined with Thales’ Signaal Multibeam Acquisition Radar for Tracking-L 
band (SMART-L) radar which is an L-band, phased array air search radar (see Figure 9. 
). The SMART-L is an example of the hybrid phased array radars described earlier. It is 
trained horizontally by moving the entire array; beamforming and steering are 
accomplished electronically (Thales 2013). 
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Figure 9. APAR (left) and SMART-L Radars (from Jane’s 2013) 

The introduction of the SPY-1/Aegis tandem introduced the first multi-purpose 
radar into the U.S. fleet. The radar performs air search and track and missile guidance 
functions as well as being used for surface search and track and gunfire support (NETC 
2000). The SPY-1 has been adapted to perform ballistic missile defense (BMD) and is 
currently the mainstay of short and intermediate range ballistic missile defense for the 
U.S. and her allies (Jane’s 2013). The APAR/SMART-L combination is another example 
of the multi-use capabilities of the active antenna array concept and it has also been 
tested in a BMD role (Thales 2013). 

The benefits of phased array antennas, combined with ever-increasing computing 
power, allow modern radar and combat systems to perform extraordinarily difficult 
military tasks. These range from detection and engagement of sea-skimming anti-ship 
cruise missiles to discrimination of a ballistic missile warhead from any surrounding 
clutter at ranges in the hundreds of miles (Jane’s 2013; Goldberg 2006). As such, active 
phased array antennas fit perfectly into the RMA’s conception of revolutionizing warfare 
via technology and thus it is no surprise that such radars had a prominent place on DDG- 
1000. The next section will examine the development of these radars for DDG-1000. 

2. History of the Dual Band Radar on DDG-1000 

In conjunction with the start of the DD-21 program in 1998 (described in Section 
B), Raytheon Integrated Defense Systems (RIDS) received a 5-year, $140 million 
development contract in 1999 to begin working on the Multifunction Radar (MFR) that 
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was intended for both DD-21 and the future aircraft carrier program, then-designated 
CVN-21 (DID, 2013). Initial concepts included an X-band multi-function radar paired 
with an L-band volume search radar (VSR), a configuration very similar to that of the 
APAR/SMART-L system. The two arrays would operate in their respective frequencies 
simultaneously, with all radar timing functions, commands, and so forth being performed 
by a common control unit. The radar controller would essentially perfonn many of the 
decision functions that are currently performed by the Aegis combat system. The concept 
of operations is shown in Figure 10. This would result in even faster processing times 
than those seen by Aegis. The system would also dispense with the need for separate fire 
control illuminators. It would also have the potential for use as an electronic warfare 
system, supplementing the current SLQ-32, and would itself be less susceptible to 
electronic attack (DID 2013). 
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Figure 10. DBR Concept of Operations (from DID 2013) 


In 2000, Lockheed Martin, the prime contractor for SPY-1 and Aegis, began an 
internal development project known as the S-band Advanced Radar (SBAR). The project 
was primarily intended to demonstrate improvements in BMD perfonnance, a rapidly 
growing priority for the United States (Friedman 2006). By 2003, Lockheed had begun 
demonstrations of SBAR at its Moorestown facility (Lockheed Martin 2003). The Navy 
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subsequently announced that the VSR portion of DBR would be S-band instead of L- 
band, and that Lockheed was to be the subcontractor for the VSR array. Raytheon would 
remain the prime contractor for the entire system, and was responsible for the common 
“back-end” of the radar suite (DID 2013). The most important element of integration 
would be the Radar Suite Controller (RSC) and its associated software. The RSC 
performs the essential task of coordinating the operations of the radar and allocating the 
radar’s timeline to meet needs (United States Navy [USN] 2012c). 

The radar change (and its impact on flow-down requirements such as footprint 
required in the ship’s deckhouse, amount and type of ancillary equipment, software 
modifications, and so on) were duly noted as a risk in a 2004 GAO report on DDG-1000 
(GAO 2004). The change also resulted in schedule delays. The GAO report is also 
interesting in that it expressed skepticism of the Navy’s confidence that all technologies 
would be mature before installation on the ship. The report also noted that the Navy had 
no fail-back plans for eight of the ten critical technologies and that schedule slips and 
additional funding would be the likely result of the over-ambitious schedule (GAO 2004). 

The DDG-1000 program plan depended heavily on the development and testing 
of Engineering Development Models (EDMs) to prove out the many new technologies on 
DDG-1000, and the DBR was no exception. In 2005, the MFR EDM completed 
Milestone B testing at the Wallops Island test facility (DID 2013). Milestone B marks the 
approval for a system to move from the “Technology Development” phase of the 
acquisition system into the “Engineering and Manufacturing Development” phase (DAU 
2011). The Milestone B decision is significant: 

Before making a decision, the MDA (Milestone Decision Authority) will 
confirm that technology is mature enough for systems-level development 
to begin, the appropriate document from the Joint Capabilities Integration 
and Development System (see Chapter 6) has been approved, and funds 
are in the budget and the out-year program for all current and future 
efforts necessary to carry out the acquisition strategy. At Milestone B, the 
MDA approves the acquisition strategy, the acquisition program baseline, 
the type of contract for the next phase, and authorizes entry into the 
engineering and manufacturing development phase. The MDA also 
certifies to the congressional defense committees that the program is 
affordable, funding is available, market research was conducted, an 
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analysis of alternatives was completed, the JROC is in agreement, 
technology has been demonstrated in a relevant environment, a 
preliminary design review has been conducted, and the program has a high 
likelihood of accomplishing its intended mission and complies with all 
statutory and regulatory requirements. (DAU 2011) 

In 2006, the MFR completed at-sea testing onboard the Navy’s Self Defense Test 
Ship (SDTS). In October of that year RIDS announced that it was on schedule with 
integration of Lockheed’s S-band array with the receiver, exciter, and signal processing 
equipment of their own VSR (DID 2013). 

In 2007, RIDS received two additional contracts to continue detailed design and 
integration of all of DDG-lOOO’s Mission System Equipment (MSE) which included the 
DBR. In October of 2007, RIDS completed installation of the Lockheed-centered VSR 
with the MFR located at the Surface Warfare Engineering Facility (SWEF) in Port 
Hueneme and began an extensive six-month period of integration testing (DID 2013). 

The summer of 2008 saw the final reduction of the DDG-1000 program by the 
Navy and the announcement of the re-start of the DDG-51 production line (as described 
in Chapter II). Work on the DBR continued, although schedule slips were beginning. In 
December 2008, a Production Readiness Review (PRR) of the MSE for Zumwalt was 
completed successfully (DID 2013). A PRR “examines a program to detennine if the 
design is ready for production and if the prime contractor and major subcontractors have 
accomplished adequate production planning” (DAU 2011, 91). While not strictly a 
review of technological progress, a “design ready for production” would be presumed to 
be a design without significant technical problems-indeed, one would expect that it 
would be tested and proven to meet requirements. 

In March of 2009, the GAO issued its annual assessment of major weapons 
programs. The report specifically described the S-band VSR as “an immature 
technology” and added: 

Land-based tests of the volume search radar prototype will not be 
completed until June 2009 — over 2 years later than planned. Upcoming 
land-based tests will be conducted at a lower voltage than needed to meet 
requirements—and without the radome. The Navy will not demonstrate a 
fully capable radar at its required power output until testing of the first 
production unit in 2011. Partly due to delays, the volume search radar will 


32 



not be installed during deckhouse construction as initially planned. 

Instead, installation will occur in April 2013—after the Navy has taken 

custody of the ship. (GAO 2009) 

The report seemed to fly in the face of the previous year’s PRR (which is chaired 
by the Navy). Delays with VSR also had potential impacts on the future carrier program 
(known by this time as the CVN-78 program). The 2010 GAO report noted that the VSR 
had “.. .progressed in maturity” but that the radar would still not be fully tested until after 
it was installed in DDG-1000 (GAO 2010, 55). In May of 2010 Raytheon announced that 
it had simultaneously tracked targets with both the S- and X-band portions of the radar 
during continued EDM testing at Wallops Island (DID 2013). 

The July 2008 reduction in ship numbers (and subsequent budget requests with 
reduced funding) resulted in a Nunn-McCurdy breach for the program. As a result of that 
breach, the Navy looked for ways to immediately reduce the procurement cost of the 
hulls. In June of 2010, the Navy made the decision to remove the VSR from DDG-1000 
(O’Rourke 2011). The VSR was not cancelled; the entire DBR will be installed on CVN- 
78. The removal of the VSR is estimated to save roughly $100 million for each of the 
three DDG-1000 hulls. Funding for integration and testing activities was also lowered for 
DDG-1000, although maintained for CVN-78 (the later “need date” for CVN-78 allowed 
those activities to be spread across further years of budget requests) (DID 2013). In the 
end, the move was justified by the DDG-1000 program manager in this way: “...we don’t 
need the S-band radar to meet our requirements...you can meet requirements with [the] 
X-band radar with software modifications” (O’Rourke 2012, 56). 

Although the VSR was removed from DDG-1000 design, the space and weight 
reservations designated for installation of the equipment will remain. This could allow for 
future expansion of the MFR, if the MFR was further developed into a BMD version, or 
future installation of the new AMDR (DID 2013). 

In addition, the MFR will have to be modified to perform many of the long-range 
search functions that the VSR was to have perfonned. Such an alteration of mission and 
requirements after nearly ten years of development was not without impact. These will be 
described in Chapter IV. The modifications were also not without cost, although the 
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Navy and the Under Secretary of Defense for Acquisition, Technology and Logistics 
(USDAT&L) believed “...the estimated cost of the MFR software modification to 
provide the volume search capability will be significantly less than the estimated 
procurement costs for the VSR...” (O’Rourke 2012, 56). 

The MFR will be installed on all three DDG-1000 ships; contracts for 
procurement of the radars were issued in 2007 and 2009 (DID 2013). A full DBR 
(including MFR and VSR) has been funded for installation in CVN-78. It remains 
uncertain if DBR will be installed on future carriers. RIDS is still performing software 
modifications to implement volume search functionality on the MFR (DID 2013). 

E. MISSILE IMPLEMENTATION ON DDG-1000 

DDG-1000 has a requirement to employ missiles for ship self-defense (O’Rourke 
2004). The missiles originally chosen for implementation on DDG-1000 were the 
Standard Missile (SM) 2 Block III-B and the Evolved Sea Sparrow Missile (ESSM). This 
section will briefly describe the characteristics and operation of the two missiles and the 
modifications required to make them compatible with the MFR. The program to 
accomplish this integration of ESSM and SM into DDG-1000 is known as the Joint 
Universal Weapons Link (JUWL) program or the ICWI-JUWL program. It is important 
to note that for both missiles, the JUWL effort was supposed to result in a technical data 
package describing the new component, several Inert Operational Missiles (IOM), and a 
Missile Communication Test Set (MCTS). The program did not include funding for 
integration efforts with the combat system, funding to transition the design to production, 
or any flight testing of the hardware (Raytheon 2012). Those efforts were expected to be 
scheduled and performed under the cognizance of the related missile programs, and 
funded through their budget requests or existing funding. 

1. JUWL Program Organization 

JUWL was not implemented as a stand-alone development program. It was 

organized as a project under the direction of the Program Executive Office (PEO) for 

Integrated Warfare Systems (IWS) Surface Ship Weapons (Office Code 3.0). The project 

manager for the effort was assigned from office code 3A (Standard Missile) and the 
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funding for the project was added as a technical instruction (TI) to the existing 
engineering and technical services contract for Standard Missile (Raytheon 2013). The 
prime contractor is Raytheon Missile Systems (RMS) in Tucson, Arizona. By necessity, 
the program needed to interact with the PEO for DDG-1000 and the PEO for DDG-1000 
combat systems as well as the prime contractor for development of the MFR and the 
DDG-1000 combat system, Raytheon Integrated Defense Systems (RIDS) in Tewksbury, 
Massachusetts. Figure 11. shows the program organization. 



Figure 11. JUWL Project Organization 


IWS 9 served as the Systems Integration Program Manager (SIPM) for all DDG-1000 
combat system elements. PMS 500 is the overall program manager. 

The JUWL Statement of Work (SOW) directs the contractor to develop link and 
guidance functionality for ESSM and SM to operate from DDG-1000. It also specifies 
that all other missile requirements are unchanged. In other words, ESSM and SM 
requirements are not altered by the missile’s implementation with DDG-1000 unless it is 

clearly called out in an interface document. Indeed, the interface documents in use on 
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DDG-1000 are legacy documents from the Aegis program. For instance, the launcher 
interface document is the Mk41 VLS interface document-despite the fact that DDG-1000 
uses the new Mk57 launcher. While ostensibly identical to the Mk41, such 
“identicalness” has not been tested in a practical environment to date. 

2. ESSM 

ESSM is an evolution of the NATO Sea Sparrow missile. Sea Sparrow is a 
medium range, semi-active homing, ship self-defense missile developed in the late 1960s 
and early 1970s (USN 2012a). Sea Sparrow uses the TAS (Doppler L-band) radar for 
initial detection of targets and the X-band Continuous Wave (CW) Mk95 director for 
target illumination. The missiles are fired from the Mk29 above-deck eight-cell trainable 
launcher (Friedman 2006). Figure 12. depicts the elements of the Sea Sparrow system. 
From left to right; they are the Mk29 launcher, the TAS, and two of the Mk95 
illuminators. 





Figure 12. Components of the SeaSparrow System 

ESSM has significant improvements over SeaSparrow, including improved 

missile kinematics and a vertical launch capability. The ESSM also features updated 

electronics, allowing it to receive mid-course guidance and terminal illumination from the 

S-band SPY-l/Aegis system or the X-band APAR system (USN 2012a; Raytheon 2013). 

The Aegis configured missiles are capable of uplink and downlinks; the APAR missiles 

are uplink only. The ESSM is currently launched from four different launchers (the 

trainable Mk29 and the vertically-launched Mk41, Mk48 and Mk56) and interfaces with 

ten different combat systems (the Mk57 NS SMS, Aegis, APAR, and other country- 

specific systems). Each combat system and radar combination requires a different variant 
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of the ESSM missile. For instance, an ESSM fired from the original SeaSparrow system 
does not feature the thrust vector apparatus required for vertical launch and does not 
contain midcourse guidance functionality (DID 2013). Figure 13. shows the various 
stages of ESSM operation. 
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Figure 13. ESSM Operation (from DID 2013) 

The ready/storage phase denotes the period onboard the ship before the missile is 
first activated for firing. The missile receives initial target information before its motor is 
ignited and the ESSM leaves its launcher. The transition phase is the period in which the 
missile conducts a pitch over maneuver to change from a vertical flight path to a 
horizontal or nearly horizontal flight path to intercept its target. During the midcourse 
phase, the ESSM continuously adjusts its flight path using information transmitted from 
the ship to intercept the target. In the acquisition/homing phase, the missile’s onboard 
seeker begins its search for the target by detecting RF energy, transmitted by the Aegis’ 
dedicated illuminator or the APAR’s ICWI waveform, reflected from the target. Once the 
target is acquired, the missile’s autopilot adjusts its flight path to intercept the target as 
closely as possible. The terminal phase begins when the ESSM and missile are entering 
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very near proximity; at that time the illumination from the signal shifts to a continuous 
signal, allowing the ESSM to have the most rapid updates possible in order to maneuver 
as close to the target as it can. The missile’s Target Detection Device (TDD) will 
detonate the warhead at the optimal time to achieve the maximum chance of destroying 
the target. 

The ESSM, like SeaSparrow, is not an area defense weapon. It was designed 
strictly for ship self-defense and has limited ability to protect other vessels. Although its 
primary targets are anti-ship cruise missiles, it does have a surface to surface mode and 
can also be employed against slower air targets (EfSN 2012a). 

The ESSM missile (Figure 14. ) is composed of a seeker, guidance section, 
warhead, transition section, and propulsion section. 
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Figure 14. ESSM sections (from DID 2013) 

The antennas for data link operations are contained in the transition section. Figure 15. 
shows the main sections of this internal arrangement: 
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Figure 15. Data Link Components 


Figure 16. shows an expanded view of the internal arrangement of ESSM, 
including interfaces with the guidance section and launcher. 



Figure 16. ESSM Guidance Components 


As described in the phases of flight, the missile receives target information and own 
ship position before launch. After launch, the missile receives target position and possible 
maneuvering commands from the ship via the transceiver. The target position information 
is relayed to the MBC, where the MBC uses the information to issue commands to the 
seeker head to point at the target. The TSC processes information from the Inertial 
Measuring Unit (IMU) and uses the IMU data, along with uplink information, to update 
the missile’s position. That calculation is compared to the target information by the 
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MBC, which in turn issues steering commands to the missile’s control surfaces via the 
TSC to the Steering and Control System (SCS). The SCS also returns feedback to the 
TSC. The ESSM will begin to search for the target at a predetermined time or when 
ordered to so by the ship. When the ESSM is close enough to the target, the illuminator 
changes to continuous transmission and the missile executes the tenninal portion of the 
flight. 

Modifying ESSM for JUWL required five major areas of effort: 

• Replacing the S-band transceiver with an X-band transceiver 

• Replacing the antenna associated with the transceiver 

• Modifying the TSC software 

• Modifying the MBC software 

• Modifying the VERR software (Raytheon 2012) 

Because ESSM already had a variant compatible with an X-band ICWI 
waveform, the ESSM portion of the JUWL program had fewer fundamental changes to 
perform in order to produce a missile that would be compatible with DDG-1000. There 
were only software changes needed to support a new transceiver/antenna combination 
and software to support the new uplink/downlink data formats of the MFR. The program 
did not have to make any changes to the guidance algorithms in the MBC. The DDG- 
1000 ESSM Concept of Operations (CONOP) for a missile flight was in fact based on the 
ESSM APAR CONOP. The ESSM is the first of the two missiles that will be integrated, 
tested, and fired from DDG-1000 during her Initial Operational Test and Evaluation 
(IOT&E) period (DID 2013). 

3. SM-2 

The Standard Missile (SM) is an outgrowth of the Navy’s earlier Terrier and 
Tartar missile programs. It is a “medium to long” range (up to 90 nautical miles), semi¬ 
active homing, area air defense missile (USN 2012b). There have been many variants of 
the missile produced to date; some were required for use on different launchers and 
others incorporated performance improvements (Friedman 2006). The U.S. Navy has 
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retired earlier versions of the SM-2, although other nations still use them (as well as the 
earlier SM-1 missile) (Jane’s 2013). 

The U.S. Navy currently employs the SM-2 Block III, SM-2 Block IIIA, and the 
SM-2 Block IIIB (USN 2012b). Block III featured flight trajectory improvements over 
earlier versions and the Block IIIA featured an improved warhead. Block IIIB 
incorporated maneuverability improvements via a software upgrade and also incorporated 
an infrared sensor for terminal homing. The SM-3 missile is a much larger variant used 
for ballistic missile defense missions. SM-6 is an extended range variant which also 
features an active seeker, enabling improved performance against certain target types and 
full utilization of the Navy’s improving Cooperative Engagement Capability (CEC). It 
may also eventually be featured in a terminal phase BMD role (DID 2013). 

An Aegis SM engagement follows a pattern similar to that of an Aegis ESSM (see 
Figure 17. ). The ship’s sensors detect and track a target and the combat system relays 
target position data to the missile. The missile is launched vertically and maneuvers to 
bring itself to the desired flight path. The missile receives S-band data uplinks and 
continues to maneuver to close on the target. It also can downlink information when 
queried. Terminal phase illumination is provided by the SPG-62 illuminators on the ship 
(NETC 2000). 


Search 


Command 

Guidance Terminal 
Guidance 


Illuminate 


- X 


Illuminate „• . , 

Terminal 

Guidance 


Track 


X 

Detect 


Search 



Figure 17. Typical Standard Missile Engagement (from Raytheon 2013) 


41 





SM-2 Block IIIB required significant work to make the missile compatible with 
the DDG-lOOO’s MFR. Significant efforts included: 

• The new frequency and waveform required modification to the missile’s 
existing receiver (referred to as Plate 1) 

• Modification of the missile’s transmitter (Plate 3) 

• Modification of the encoder/decoder (Plate 4) 

• Complete redesign of the existing digital signal processor (Plate 2) 

• A new software build to support the ICWI waveform, transmit and receive 
link messages to the MFR, and include new guidance algorithms for the 
missile (Raytheon 2013) 

A modernization effort for Plate 2 had already begun to support the Standard 
Missile program as a whole, addressing obsolescence issues and inserting components to 
accommodate future growth. It was known as the Digital Signal Processor- 
Modernization or DSPM. JUWL was directed to integrate with that effort to ensure that 
the DSPM would meet JUWL requirements (Raytheon 2013). 

The effort required to make SM compatible with DDG-1000 was not trivial. It 
required significant hardware and software efforts. The SM portion of JUWL is 
scheduled for its critical design review (CDR) in late summer of 2014 (Raytheon 2013). 

4. Missile Deliverables and Changes 

The JUWL effort had several significant events affect the program since it was 
initiated. First, the original intent for the SM JUWL was to add X-band functionality to 
the missile but retain S-band compatibility. This would result in a truly “universal” 
component, reducing costs and limiting the amount of configuration changes in the SM 
program. This requirement was dropped in 2010 (Raytheon 2013). 

In 2010, the Navy restructured the entire DDG-1000 effort as a result of the 
Nunn-McCurdy breach and subsequent budget request changes. As noted, funding for 
integration of the VSR and MFR was cancelled; that funding had also been used to 
support the JUWL effort. In January of 2011, no additional funding had become available 
to support the JUWL TI and the prime contractor stopped the effort and re-assigned or 
released the engineering staff working on the project (Raytheon 2011). Additional 
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funding was finally allocated in June of 2011 and RMS began re-assembling its team. 
This delay resulted in some significant schedule slip for both ESSM and SM. While this 
was certainly not the Navy’s intent when it restructured the program in response to Nunn- 
McCurdy, it had significant impact on the prime contractor’s development effort. 

In the summer of 2012, the Navy made the decision to change the DDG-1000 SM 
missile from the Block IIIB type to the older Block IIIA type (Raytheon 2013). This had 
significant impact because the Block IIIA had different hardware and software from the 
IIIB. In particular, the IIIA does not contain the IR hardware for tenninal phase, does not 
contain the software-driven Maneuverability Upgrade (MU), and is equipped with a 
different TDD. All of these changes affect JUWL. The absence of the IR hardware 
altered the physical layout of the plates that JUWU was designing and also affected the 
guidance software. The different TDD also affected guidance as the missile may need to 
fly different flight paths against different targets. The absence of MU could also have 
affected guidance; however, the program later decided to include MU functionality in the 
JUWL software build (Raytheon 2013). 

Finally, the MFR itself has changed in order to accommodate the addition of some 
of the functionality of the deleted VSR. The heart of a multi-function radar is the 
management of the radar’s resources. As described earlier, a multi-function radar 
performs all of the functions previously performed by multiple conventional radars. Thus, 
a multi-function radar must direct its RF energy, receive signals, process those signals, 
and then potentially redirect its RF energy based on its analysis. The radar may need to 
direct some RF energy toward midcourse guidance of a missile, and may also need to 
illuminate a target for the terminal phase of an engagement, while simultaneously 
tracking multiple other targets and searching for new targets. 

Consider the following example. A multi-function radar is operating in a general 
search mode (which is pre-established, based on the operating environment and expected 
threats). The radar receives return reflections from a certain bearing, range and altitude 
which I will call position A. The radar analyzes these returns with predetermined 
algorithms and based on the strength and number of repeated reflections determines that 

the reflections are, in fact, a target. It then implements “tracking” algorithms which 
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radiate RF energy to ensure that the radar continues to receive reflections from the target. 
The algorithms use the analysis of the reflections to predict the location of the target 
allowing for error. Faster targets require more reflections in order to keep those predicted 
positions accurate. Hence the radar is constantly predicting position B for the target, then 
position C, and so on. There are time delays associated with the receipt of reflections, 
processing, predictive calculations, commands to the antenna to radiate toward a certain 
new position, and the reiteration of the process. The delays can be significant, even if 
those times are measured in fractions of a second, when the targets are moving at high 
speed and/or are constantly changing course or speed. When a radar element is directed 
to perform a certain function, it cannot perfonn another. Thus, if a group of elements are 
radiating to illuminate a target for the tenninal phase of an engagement, they cannot 
radiate to search in another sector. 

This entire process is radar resource management. It is the key improvement of 
the multifunction radar over a system utilizing conventional radars. A conventional radar 
cannot perform these re-directed tasks. The combat system is limited to tracking targets 
as fast as the radars can perfonn and can “command” only a very limited set of sensors. 

A single target is a trivial problem for a multi-function radar, given the computing 
power available to perform the calculations and issue the subsequent commands. 
However, the system can be overwhelmed or “saturated” by high numbers of targets and 
conflicting demands for resources. 

The following brief example highlights the complexity of the software needed to 
coordinate all of the possible combinations of functions for a multi-function radar 
operating in a target dense combat scenario. Radar resource management, also referred to 
as radar timeline or radar timeline budget, is the key consideration for effective 
employment. Therefore, when the MFR program was directed to implement new 
functionality after almost ten years of development, it was a major change. Some of the 
changes have only recently been conveyed to the JUWL program. The most significant 
impact may be that the MFR has “maxed out” its radar timeline in certain scenarios and 
therefore may need to consider tactical employment changes to support any potential 
changes in the future. 
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F. SUMMARY 

Most of the new combat systems developed for DDG-1000 have experienced 
significant technical challenges or have seen significant changes in scope. The AGS 
experienced several years of delay in developing a suitable projectile. Although not 
discussed in this paper, the DDG-1000 Undersea Warfare (USW) systems had 
developmental delays and technical challenges (DID 2013). The DBR experienced delays 
in developing the S-band VSR, which was subsequently removed from the ship. That 
removal drove changes into the MFR, which is still in the process of incorporating 
changes and assessing their impact on performance and radar timeline. The JUWL 
program had to develop new hardware and software for both ESSM and SM and changes 
to the MFR may yet have significant impact on both missiles. 
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IV. PROCEDURES, STANDARDS AND BEST PRACTICES 


A. INTRODUCTION 

The federal government, the Department of Defense, and the Navy have 
enormous numbers of legislative mandates, governing regulations, and policy directives 
concerning the development of systems for government use. This thesis will focus only 
on DOD-specific directives and regulations. 

This chapter will briefly describe the DOD’s framework for acquiring systems. It 
will also list key concepts of systems engineering that contribute to successful system 
development. It will also examine current management organizational constructs that 
have been created in an attempt to help management personnel, both civilian and 
military, succeed in this challenging environment. 

B. THE DEFENSE ACQUISITION SYSTEM 

The Defense Acquisition System (DAS) is intended to produce successful 
acquisition programs. A successful program “...places a capable and supportable system 
in the hands of users (the warfighter or those who support the warfighter), when and 
where it is needed, at an affordable price” (Defense Acquisition University (DAU) 2010, 
5). The tenn “Defense Acquisition System” usually refers to the specific rules governing 
the administration of acquisition programs in the DOD, but is sometimes more generally 
applied to the interactions of Congress, the executive branch, and industry (DAU 2010). 
For purposes of this thesis, DAS will refer to the specific administration of military 
programs and the tenn “acquisition environment” (AE) will refer to the broader 
interaction of Congress, the President, industry, and the respective influences of public 
opinion, media, and so forth (see Figure 18. 

The executive branch includes the presidential administration, the uniformed 
services, and all civilian staff in the DOD. The legislative branch includes all 
Representatives and Senators as well as their personal staffs and the full-time 
Congressional staff. Industry encompasses all of the major defense industry corporations 

and smaller businesses supporting the defense industry or the DOD (DAU 2010). 
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Figure 18. The Acquisition Environment (from DAU 2010, 2) 

The DAS is just one of three so-called “decision support systems” created by 
Congress and the Executive Branch to determine what systems should be acquired, how 
they will be paid for, and how they will be produced (see Figure 19. The others are the 
Planning, Programming, Budgeting and Execution (PPBE) process and the Joint 
Capabilities Integration and Development System (JCIDS) (DAU 2010, 18). 
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Figure 19. Three Decision Support Systems (from DAU 2013, 6) 
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The JCIDS process analyzes projected military capability needs and shortfalls 
which are submitted by the various regional and functional Combatant Commanders 
(COCOMs). If the JCIDS analysis determines that there is a need for a new military 
system to meet these capabilities or shortfalls, the DOD names a Defense Acquisition 
Executive (DAE) to oversee the fulfillment of the requirement. The basic JCIDS process 
is shown in Figure 20. 



Figure 20. JCIDS Overview (from DAU 2010, 36) 


The DAE, in turn, determines the proper chain of command to manage the 
development of the new system and establishes the responsible program office (see 
Figure 21. The DAS allows for a great deal of flexibility in organization, and not every 
program will align neatly with the chain shown in the figure. Because of cost, national 
strategic importance, or other reasons, some programs will not feature a Program 
Executive Office (PEO) between the program manager and the Component Acquisition 
Executive (CAE). Conversely, for service-specific or less costly programs, the DAE may 
delegate authority to the service itself. 
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Figure 21. Generic Acquisition Chain of Command (from DAU 2010, 25) 


The DAS is perhaps best described as a phased sequence of technological 
development intended to produce a successful system. It is a management construct and 
is designed to be flexible in application. For example, not every program begins at the 
first stage (material solution analysis). Some programs which feature a proven design 
applied in a new environment could enter at a later phase (DAU 2011). 

Spaced throughout the various phases are a series of demonstrations, technical 
reviews, and programmatic “milestone” decisions. A high-level view of the DAS is 
shown in Figure 22. The intention of the DAS is to ensure that the original requirements 
of the system are met by its design. It is also intended to ensure that all aspects of a 
system throughout the system’s anticipated life cycle are addressed in the early stages of 
design and development. 
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Figure 22. DAS Overview (from DAU 2010, 41) 


For example, design of the system should take into account the anticipated 
maintenance cycle of the system, or conversely, the system should be designed to meet 
the maintenance requirements needed by the warfighter. These decisions can have an 
enonnous impact on system cost and development time. Continuing with the maintenance 
example, consider the implications of maintenance of a shipboard diesel engine compared 
with a surveillance satellite. A great deal of diesel engine maintenance and repair can be 
performed by the ship’s engineers, and the engine’s consumables and spare parts can be 
introduced into the existing ship supply system. The satellite, on the other hand, will 
likely never receive a maintenance visit of any kind. Hence the satellite must be designed 
and manufactured to an enormously higher standard for reliability, workmanship, and 
overall quality. Such demands are commensurately more expensive. 

Other examples of system design which should be addressed in the early stages of 
design include (Blanchard and Fabrycky 1998): 

• Required Performance 

• Physical characteristics 

• Maintenance concept 

• Reliability 

• Transportability 

• Human Factors (ergonomics) 
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• Safety 

• Producibility 

• Testability 

• Facilities 

• Support personnel 

• Disposability 

• Obsolescence 

• Future improvements 

• Packaging, handling, storage and transportation 

• Environment 

The list shown is by no means complete. Many factors could be related; consider 
how physical dimensions of the system could be limited by the intended transportation 
method. This consideration of the total life cycle of a design, known as “life-cycle 
engineering,” is a hallmark of the systems engineering process and one of the essential 
elements for design success (Blanchard and Fabrycky 1998). 

The PPBE system is the method by which the DOD produces its budget. It is a 
complicated process and will only be briefly described. The process was originally 
implemented by Secretary of Defense Robert McNamara in 1962 (Anny Force 
Management School (AFMS) 2011). The key feature of McNamara’s new process was an 
attempt to plan for and control change. Instead of producing and submitting single year 
budgets independently (as the services had done previously), the services now submitted 
five year projections to the Office of the Secretary of Defense (OSD) to be consolidated 
into a Future Years Defense Plan (FYDP). This is the main tool by which OSD (and by 
extension the president in his role as commander-in-chief) determine the size and type of 
military forces to procure and operate to meet its strategic needs (AFMS 2011). The 
FYDP is probably best considered as a five-year spending plan, which the DOD uses to 
submit its annual budget to Congress. Once the budget is enacted into law, the DOD then 
spends (executes) the budgeted funds. 
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When changes to the five year plan are deemed necessary, the services submit 
change requests to OSD for consideration. To manage the number of change requests 
produced, the OSD issues strategic and budgeting guidance to the services each year 
which highlights DOD priorities and adjustments to overall strategy. Thus, the PPBE 
system is a never-ending cycle of planning, spending, and accommodating changes in 
national strategy and military priorities that in turn affect budgets. 

Each service has an internal process to produce its five year inputs as well as the 
current years’ budget requests. This is driven by OSD guidance as well as by the 
service’s assessment of its needs to meet national strategic guidance. These budget 
requests are consolidated by OSD and flow into the president’s budget submission to 
Congress (see Figure 23. ). 
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Figure 23. PPBE Service & OSD Actions (from DAU 2011, 20) 


Congressional action on the budget follows the process shown in Figure 24. 
Congress often disregards the recommendations of OSD and the individual services in 
order to fund programs it deems important or cancel programs it deems too costly. These 
Congressional decisions then affect the program estimates and budgets for subsequent 
years. 
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Figure 24. Congressional Action on the Budget (from DAU 2011, 21) 

This brief summary does not capture the many intricacies of budgeting, 
scheduling, and reporting needed by the DOD to operate in the acquisition environment. 

The complex interactions of the PPBE, JCIDS, and DAS are one of the main 
reasons that the DOD employs such a vast bureaucracy. Cost analysts, contracting 
specialists, and administrators are needed to fulfill the voluminous reporting and 
budgeting documentation needed by thousands of individual acquisition programs across 
all the services. A quick glance at the latest version of the “Integrated Defense 
Acquisition, Technology, & Logistics Life Cycle Management System” chart, kn own as 
the “wall chart” or “horse bla nk et” chart, will give some idea of the multitude of 
activities and procedural steps faced by even a relatively small-scale acquisition program 
(DAU 2013, 11). 

The DOD recognizes this complexity and has taken steps to aid the services and 
their respective program offices in navigating through the process. The next section will 
discuss the DOD’s systems engineering infrastructure and describe how the infrastructure 
is designed to aid in the design, development, and production of effective and affordable 
military systems. 
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c. 


SYSTEMS ENGINEERING IN THE DEPARTMENT OF DEFENSE 


The DOD has recognized the importance of implementing robust systems 
engineering principles into the DAS and into acquisition program management. The OSD 
established an additional Office of the Deputy Assistant Secretary of Defense for Systems 
Engineering (ODASD-SE) in order to provide guidance and oversight for implementing 
quality systems engineering in the DOD. The Office’s mission statement is: 

...to develop and grow the Systems Engineering capability of the 
Department of Defense—through engineering policy, continuous 
engagement with Component Systems Engineering organizations, and 
substantive technical engagement throughout the acquisition life cycle 
with major and selected acquisition programs. We apply best engineering 
practices to: 

• Help program managers identify and mitigate risks 

• Shape technical planning and management 

• Support and advocate for DOD Component initiatives 

• Provide technical insight to OSD stakeholders 

• Identify systemic issues for resolution above the program level. (ODASD- 
SE 2013) 

Numerous studies have detennined that disciplined implementation of systems 
engineering principles, which can fall under Blanchard and Fabrycky’s general term of 
“life cycle engineering,” correlate directly to improved project performance in terms of 
cost, schedule, and product performance. For example, a 2012 study conducted by the 
Systems Society of the International association of Electrical and Electronics Engineers 
(IEEE) and the National Defense Industrial Association (NDIA) showed that only 15% of 
projects that failed to apply thorough and early SE achieved established project success 
criteria. The projects that did implement early and effective SE achieved a 57% success 
rate. The difference was even greater for those projects deemed to have a high 
complexity rating (Elm and Goldenson 2012, 74). This is not a new result. The related 
disciplines of systems engineering and project management have achieved near-universal 
acceptance in engineering and industry for over 60 years (Stuckenbruck 2008; Honour 
2013). As we shall see in later sections of this thesis, however, acceptance does not 
automatically translate into effective application. 
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Congress also established a system of professional education for personnel 
employed in the DAS with the passage of the 1990 Defense Acquisition Workforce 
Improvement Act (DAWIA). The law stemmed from the 1986 Packard Commission 
Report that concluded military and civilian officials involved in defense procurement 
were typically undertrained and/or inexperienced (Fox 2011). DAWIA established a 
robust system of training and certification in a variety of career fields for both uniformed 
and civilian personnel in the DOD (DAU 2010). 

ODASD-SE continues to stress the development of a professional acquisition 
workforce. Consider the following statement from the ODASD-SE: 

One of our greatest challenges may be in our approaches to building great 
people and teams and improving how we recruit, grow, and mature the 
technical and systems engineering professionals who will successfully 
deliver today and tomorrow’s critical defense systems. We are working 
closely with the DOD Components to enhance the capability and capacity 
of the technical management workforce. As an example, we are 
identifying workforce competencies crucial for executing systems 
engineering and production, quality, and manufacturing functions within 
acquisition programs. (ODASD-SE 2013) 

The Defense Acquisition Guidebook includes a significant chapter on systems 

engineering and ah of the services have their own systems engineering guidance for 

program managers. For example, the various naval systems commands combined to issue 

the Naval Systems Engineering Guidebook and the Air Force publishes The Early 

Systems Engineering Guidebook and the Systems Engineering Primer & Handbook. 

These guides cite academic and professional literature concerning SE definitions, 

techniques, and best practices. Examples include the Systems Engineering Handbook 

published by the International Council on Systems Engineering (INCOSE) and the IEEE 

Systems Journcd. ODASD-SE maintains a standards and specifications database of over 

111,000 documents (ODASD-SE 2013). It also provides a technical interface with the 

International Organization for Standardization (ISO). 

The creation of systems engineering directorates in OSD and ah the services, as 

well as the voluminous amount of SE guidance for program managers and acquisition 

professionals, is testament to the importance that the DOD attaches to effective SE as a 

means to “solve” the problems that have plagued military acquisition. Given that 
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emphasis, it is important to describe some of the SE principles that lead to program 
success. 

1. Requirements 

Establishing requirements that are clear, valid, achievable, and remain constant is 
one of the most commonly cited necessities for the completion of a successful 
engineering project (Defense Acquisition Guidebook (DAG) 2013). Requirements are the 
expression of the “need” that drives creation of the system. They are, by necessity, 
established early in the life of the program. The first phase of the DAS - the material 
solution analysis phase-is fundamentally the process of establishing requirements, 
validating and verifying them, and creating the concepts and project plans to meet those 
requirements (see Figure 25. ). 
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Figure 25. Material Solution Analysis Phase (from DAU 2011, 83) 


Blanchard and Fabrycky’s Systems Engineering & Analysis, a widely used 
systems engineering textbook, describes requirements this way: 
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...(T)rue system requirements need to be well defined and specified, and 
the traceability of these requirements from the system level downward 
needs to be visible. In the past, the early “front-end” analysis as applied to 
many new systems has been minimal. The lack of defining an early 
“baseline” has resulted in greater individual design efforts downstream. 

Many of these are not well integrated with other design activities, causing 
costly modifications later on. (Blanchard and Fabrycky 1998, 24) 

Similarly, the National Aeronautics and Space Administration (NASA) NASA 
Systems Engineering Handbook states “...clear and unambiguous requirements will help 
avoid misunderstandings when developing the overall system and when making major or 
minor changes” (NASA 2006, 32). The Defense Acquisition Guidebook states that 
“...poorly written requirements can lead to significant problems in the areas of schedule, 
cost, or perfonnance, and can thus increase program risk” (DAG 2013, 158). 

The Defense Acquisition University provides the mandated training for program 
managers and systems engineers specified by the DAWIA act. One of its foundation 
courses is “Systems Engineering Fundamentals” which contains the following attributes 
of a good requirement: 

It must be complete and contain all mission profiles, operational and maintenance 
concepts, utilization environments and constraints... 

Requirements analysis should result in a clear understanding of: 

Functions: what the system has to do, 

Performance: How well the function has to be performed, 

Interfaces: Environment in which the system will perfonn. (DAU 2001, 
36-37) 

Establishing clear and comprehensive requirements fulfills two purposes in a 
project. First, it ensures that the project will meet its intended purpose and therefore that 
the project is satisfying the “big picture.” Although this seems self-evident, more than 
one project has been initiated because of “.. .personal interest or political whim, without 
first having adequately defined the requirement” (Blanchard and Fabrycky 1998, 46). 
Second, requirements drive the functional analysis, which ultimately produces the system 
conceptual design. The conceptual design, in turn, feeds the creation of the detailed 
design and the eventual configuration to be fielded. Hence it is essential that the 


59 



requirements be complete so that the system designers account for every system need 
without having to reallocate or redesign, both costly and time-consuming activities. 

2. Integration 

Integration is another essential element of systems engineering. Integration of 
system elements is what produces the benefit of a system (Madni 2012). In many 
discussions of systems engineering, integration is approached as one of the many 
required processes on the “upward” portion of the SE “V” model (shown in Figure 26. ) 
(Blanchard and Fabrycky 1998). 
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Figure 26. V Model of Systems Engineering (from DAG 2013) 


In this “process” focused point of view, system integration (SI) can be 
accomplished using a variety of techniques. All of these techniques stem from the 
traditional “waterfall” model of SE (precursor to the “V”); several were developed in 
response to the ever-increasing complexity (and consequently more difficult integration) 
of modern systems (Madni 2012). Methods of integration include the layered integration, 
“plug-and-play” integration, horizontal integration, and build integration (Madni 2012). 
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While certainly a valuable benefit of the SE process, if one views SE as a series of 
processes to be accomplished, integration is much more fundamental than merely a 
process to ensure system components are compatible. 

Professors Gary Langford and Derek Hitchins have presented complimentary 
views of the critical importance of integration to the success of any SE project. Hitchins 
approaches integration from his “macro” level discussions of systems thinking and the 
benefits of SE design “synthesis” versus the traditional “reductionist” engineering 
approach (Hitchins 2013). Langford, on the other hand, presents a “micro” level view of 
integration and creates a framework for conducting integration and analysis while also 
emphasizing the absolute centrality of integration to engineering success (Langford 
2012 ). 

Hitchins’ views on systems engineering and integration can be found in his 
several books and numerous essays published at his website “Systems World” 
(www.hitchins.net) . His “First Principle of Systems” and “Corollary to the First 
Principle” are particularly useful: The properties, capabilities, and behavior of a system 
derive from its parts, from interactions between those parts, and from interactions with 
other systems. Altering the properties, capabilities, and behavior of any of the parts, or 
any of their interactions, affects other parts, the whole system, and interacting systems 
(Hitchins 2013). That definition captures the importance of understanding that a system 
can produce results greater than any of its constituent parts. He uses the term 
“emergence” to denote this phenomenon and emphasizes that emergence is the key to 
understanding the value to be gained by pursuing systems engineering principles. 

A naval anti-ship cruise missile (ASCM) defense system is a good example of 
emergence resulting from integration. Radars and other sensors cannot defend the ship. 
Electronic warfare may defeat some threats but not others; some threats may or may not 
be susceptible to decoys; and defensive weapons (guns and missiles) may or may not 
defeat still other threats. But a combination of all of those systems provides the defending 
ship a higher probability of defeating enemy missiles. Hence, the process that creates 
emergence (integration) has to be the centerpiece of any development effort. 
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Langford’s recent text Engineering Systems Integration: Theory, Metrics, and 
Methods presents an integration framework that is abstract enough to be applied to any 
system regardless of nature or complexity (Langford 2012). It considers object 
integration in terms of the exchange of energy, matter, material wealth, and information 
(EMMI) as influenced by various boundary conditions - physical, functional, and 
behavioral. Langford also proposes a list of seven integration principles, gathered from 
numerous case studies, that “...can help guide decisions” concerning the conduct of an 
engineering project (Langford 2012, 10). The principles are listed in Appendix A; their 
applicability to DDG-1000 missile integration will be discussed in Chapter V. 

Integration is not easy, and it is not a single well-defined process. Instead, it is 
often practiced in an ad-hoc manner or in accordance with the opinions of various 
program managers or engineers (Madni 2012, 3). However, Langford and Hitchins make 
compelling arguments that integration is the most important part of system development 
because it is the process that produces emergence. Chapter V will assess integration for 
DDG-1000 from this viewpoint. 

3. Management and Organization 

The practice of project management has long been associated with systems 
engineering and is critical to the eventual success of any engineering effort (Blanchard 
and Fabrycky 1998; DAU 2001). Just as a well-organized effort will fail without quality 
engineering, quality engineering alone will not guarantee project success. Indeed, one can 
reasonably argue that successful engineering is a byproduct of successful management. 

What does engineering management entail? At a minimum, management connotes 
planning, staffing, monitoring and controlling the design, development, testing, and 
production of a system (Blanchard and Fabrycky 1998). It therefore covers the initial 
problem analysis and customer requirements, resulting in analysis of alternatives and 
recommended solutions. It includes the creation of a detailed work breakdown structure 
(WBS) that will inform budget estimates. It also includes completion of functional 
flowdown analysis, creation of derived requirements, establishment of technical reviews 
and test activities, and creation of a mechanism to review design changes and resolve 
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technical problems. Lastly, in includes the preparation of key program documents that 
capture the items listed. These key documents include an integrated master schedule 
(IMS), a systems engineering management plan (SEMP), the WBS, and a test and 
evaluation master plan (TEMP). 

The elements of management described entail the organization and activities that 
must be conducted by the designer/producer of the system in question. In the Department 
of Defense, however, the purview of managing an acquisition project is much greater. As 
described in earlier sections on the DAS and the acquisition environment, the project 
manager must contend with a budgeting process in which his or her project is likely one 
small piece of a much larger puzzle. The manager must also contend with possible 
requirement changes and oversight activities that increase the demand on project 
resources. Lastly, elements of design, test and support for the system being designed are 
not under the control of the project manager. Thus, the project becomes dependent on 
other organizations with their own schedule, budget, and performance constraints. 

The DOD initiated the concept of Integrated Product and Process Development 
(IPPD) in the early 1990s in order to foster the communication and teamwork necessary 
to produce a successful project in the acquisition environment (Blanchard and Fabrycky 
1998, 634). A central element to IPPD is the creation and use of Integrated Product 
Teams (IPTs) to manage the interaction of program functions (logistics, production, etc.) 
with the personnel/organizations that will carry out the function (contractors, DOD test 
organizations, etc.). Figure 27 shows a traditional program structure, a purely functional 
structure, and a matrix structure utilizing IPTs. 
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Matrix Structure 
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NOTE 1: Functional titles shewn are notional. 
NOTE 2: IPTs often align with WBS elements. 


Figure 27. Program Organization Examples (from DAU 2011, 56) 


The IPPD/IPT construct is a multi-disciplinary task approach and as such it is 
extremely dependent on clear lines of communication to function efficiently (Blanchard 
and Fabrycky 1998, 628). Stating a need for good communication in a large and complex 
organization is something of a truism; however personal experience has shown that there 
are still many occasions in which one element of a program was unaware of important 
developments elsewhere in the project. The IPTs must also be empowered to make 
decisions related to their functional area and ensure that the ramifications of such 
decisions were considered beforehand. 
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A matrix organization as shown will inevitably encounter issues that will have to 
be resolved at a higher level. In the end, the responsible program manager (PM) must 
make the difficult decisions. However, analysis of the matrix organization and the DAS 
show that the PM will often not have the final say, and may have to defer to a higher 
level authority or a component head for a decision in a certain area. The implications of 
this organization for DDG-1000 will be examined in Chapter V. 

D. SUMMARY 

Defense acquisition is a complex process. The DOD has made substantial efforts 
to implement systems engineering and the life cycle viewpoint into the acquisition 
process. Congress has established professional education and certification requirements 
to emphasize the importance of SE in the DOD. 

Successful SE must include early establishment of quality requirements for the 
system. Integration activities produce the emergent behavior that gives the system its 
value, therefore integration must also be emphasized from the start of the program. The 
DOD has implemented the IPPD/IPT model into program management in order to 
improve communication and coordination between the multiple disciplines involved in 
developing a system, including various design and engineering areas, logistics planning, 
maintenance planning, in-service support, and so on. 

Having discussed the pertinent aspects of the defense acquisition process and the 
key systems engineering principles inherent in all successful programs, we will now turn 
our attention to analysis of the DDG-1000 program with respect to requirements, 
integration, and organization. 
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V. ANALYSIS 


A. INTRODUCTION 

At this point we have developed our understanding of the history and background 
of the DDG-1000 program including its combat system components. We have also 
discussed the DOD’s standard planning, acquisition and budgeting processes and their 
efforts to incorporate Systems Engineering where appropriate. Armed with that 
background, we can analyze the success or failure of DDG-1000 missile integration with 
respect to the key systems engineering tenets of requirements, integration and 
organization. The analysis will be further informed by additional illustrations, best 
practices, and lessons learned from other DOD and commercial industry programs. 

B. REQUIREMENTS 

Chapter IV gave several statements from a variety of systems engineering 
authorities on the absolute criticality of clear, comprehensive requirements for a 
development program. These sources were academic (Blanchard and Fabrycky) and from 
the DOD (the Defense Acquisition Guidebook). There are many other systems 
engineering textbooks and definitions that similarly echo the importance of clear 
requirements. 

Given the widespread recognition of the importance of “good” requirements, one 
would believe that the DOD would take great pains to ensure clear and comprehensive 
requirements were established for all of its programs. Yet poor requirements definition 
continues to plague the DOD. For example, a 2003 report from the NDIA stated 
“...requirements definition, development, and management is not applied consistently 
and effectively...” (NDIA 2003). The report continued: “the Government, for the most 
part...do not follow their requirements process effectively...there is a serious lack of 
upfront and continuous requirements development and management, including 
management of requirements changes” (NDIA 2003). 

In 2006, Secretary of the Navy Donald Winter stated “...the Navy needs to do a 

better job of stabilizing requirements. Scrubbing requirements at the beginning of a 
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program is critical. But we also need to strictly control new requirements in existing 
programs...” (Winter 2006, 4). One of ODASD-SE’s top six priorities for 2013 is to 
“...support realistic program formulation through the application of development 
planning and early systems engineering...” and “...identifying early systems engineering 
gaps and deficiencies...” (ODASD-SE 2013). 

A 2010 Air Force Institute of Technology (AFIT) case study analysis of eight 
major acquisition programs, both successful and unsuccessful, found that inadequate or 
changing requirements were a major reason for poor perfonnance in every unsuccessful 
program; conversely, all of the successful programs were found to have clear 
requirements that were adhered to throughout development (AFIT 2010). 

Missile integration for DDG-1000 has three significant potential problem areas in 
tenns of requirements; each concern applies equally to both ESSM and SM: 

• Top level requirements for the missile have not been established, creating 
potential performance risk 

• The directive to use legacy system requirements creates technical risk 

• Requirements have been changed late in the development process, creating 
technical and integration risks 

Each concern will be discussed individually. 

1. Top Level Requirements 

Top level missile requirements have never been formally established for the 
JUWL program (IWS3 2012). Error! Reference source not found, shows a simplified 
diagram of the flow of requirements for DDG-1000 missile integration. 
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Figure 28. DDG-1000 Requirements Flow (from IWS3 2012) 


The DDG-1000 contractor developed a set of system performance documents 
(SPDs) which included system performance specifications (SYS) and system 
environment specifications (SENV). The SPDs were then decomposed and allocated to 
one of the various segments (DBR, for example). The DDG-1000 contractor did not 
include a missile segment in its analysis. Therefore, the requirements decomposition did 
not allocate any functional or performance requirements to the missile and did not define 
any physical or logical interfaces between ship systems and the missile. 

Working group meetings between the ship combat system and missile programs 
were held in 2005 and the gap in requirements flowdown was discussed. A need for pre- 
and post-launch interface control documents (ICDs) to define data link requirements was 
agreed to but ship program representatives initially maintained that no missile 
requirements were needed because the missiles were assumed to perform as they would 
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when launched from an Aegis platfonn (IWS3 2012). Further discussion of the 
differences between DDG-1000 and Aegis requirements such as CONOPs, threats, hull 
environments, and so forth led to an agreement to develop missile requirements. 
However, the first draft of DDG-1000 missile top level requirements (TLRs) prepared by 
the combat system program office copied existing Aegis requirements and interface 
documents. Continued discussions between IWS3 (the JUWL development manager) and 
IWS11 (the SIPM for DDG-1000 at the time) could not produce an agreement on the 
content and detail of the missile TLR. The differences continued to center on the 
suitability of using existing Aegis requirements in the new DDG-1000 environment; the 
effort was abandoned in 2007. The end result was that all legacy SM and ESSM 
requirements were considered “good enough” and were to be used as-is; the only 
requirements changes were those included in the pre- and post-launch ICDs to define data 
link requirements (IWS3 2012). The SOWs presented to the JUWL prime contractor have 
reflected this legacy requirement and have thus limited the level of effort in the JUWL 
program. 

0 depicts the flowdown used to achieve the current JUWL prime item 
development specifications and gaps that still exist in requirements. 
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Note: APAR Mssile Indicates Source for ICW Requirements Originally De/elopedfor APAR Based Corrbat Systems 


Figure 29. DDG-1000 Requirements Flow (from IWS3 2012) 


The gaps in missile TLRs create uncertainty of performance expectations and the 
Navy’s capacity to measure missile performance for DDG-1000. It also results in 
technical risk, as JUWL development does not include any mechanism for investigating 
or developing performance improvements in the missiles. The absence of TLRs is clearly 
in contradiction to the emphasis that SE places on clear requirement definition. 

2. Legacy Requirements 

Using legacy requirements produces risk in other areas besides mission 
performance. DDG-lOOO’s mechanical, electrical, and electromagnetic environment will 
be different from that of Aegis ships. Potential for electromagnetic interference (EMI) 
from other emitters on DDG-1000, as well as potential hazards of electromagnetic 
radiation to ordnance (HERO) from those emitters, are not addressed in the JUWL 
program because legacy requirements are in place. Consider that the MFR is an entirely 
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new radar, operating in a new frequency, with new power levels and waveforms. While 
EMI or HERO issues are not a certainty, they are certainly a potential problem. And more 
mundane, but no less important, concerns such as the vibration profile of the new hull 
and the differing proximity of the launchers (and thus missiles) to other hull, mechanical, 
and electrical (HM&E) systems could result in a situation where a legacy requirement is 
inadequate or unsafe. 

This is not to say projections of DDG-1000 environments are not available or that 
no consideration has been given to these issues. Projections and models of other systems 
are available. But the JUWL developer is limited to providing a legacy missile with a 
new data link, and thus the opportunity to design in response to even the projected 
environments is lost. As the lead ship in a new class, DDG-1000 will likely undergo a 
variety of surveys to detennine EMI, HERO levels, vibration profiles, near-miss shock 
levels, and so on. If legacy missile requirements are found to be lacking, the entire DDG- 
1000 program will face cost and schedule penalties in order to “make up” the difference 
between legacy needs and DDG-1000 needs. 

3. Requirement Changes 

DDG-1000 and JUWL have had two significant changes since 2009 that have 
affected component design. As described in Chapter III, the 2010 program restructuring 
following the program Nunn-McCurdy breach deleted the VSR from the ship. Some VSR 
tasks were re-allocated to the MFR, which entailed radar resource management changes 
and attendant software alterations in the radar and the combat system. These software 
alterations impact the MFR radar timeline. Timeline changes, in turn, have the potential 
to impact missile performance. For example, the radar may send fewer guidance 
commands to a missile in flight, reducing the accuracy of the missile. 

These radar timeline changes have to be analyzed, modeled, and then installed 
into the combat system. Those models must then be made available to the missile 
designers for assessment of potential changes in the missile. At this time, the combat 
system contractor has not made a DDG-1000 specific weapon control element (WCE) 
model available for missile program use (IWS3 2012). Therefore, the JUWL developer 
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has proceeded with the assumption that DDG-1000 will be consistent with the Trilateral 
Frigate Cooperation (TFC) software that integrated SM with the APAR system (IWS3 
2012). It is also unclear if the current radar model adequately reflects any changes 
resulting from VSR removal. The combat system (C/S) developer has not made a full 
radar model available to JUWL; they have only provided static radar data as modeled for 
a cross-section of radar scenarios (IWS3 2012). The entire system will eventually be 
tested during operational evaluation. Any errors or discrepancies discovered at such a late 
stage in the program will have major cost or schedule ramifications. 

In 2012, the Navy replaced the SM-2 Block IIIB missile with the SM-2 Block 
IIIA version. This entailed a sizeable design and software change for JUWL as well as 
changes for the combat system. The internal arrangement of components among the four 
guidance section plates is different in IIIA missiles and IIIB missiles. Therefore, JUWL 
designers had to reallocate JUWL components at the circuit card assembly (CCA) level 
and repeat their design validation and verification activities. The IIIB missile also has 
different “base” software than the IIIA missile and JUWL designers had to re-perform 
their software analysis and some software testing before they could import their JUWL 
specific software into IIIA. The software situation was further complicated by a 
subsequent decision to include the MU software update into the IIIA build-the JUWL 
software build will be the first IIIA missile to incorporate MU. 

The missile change also impacts the combat system. IIIA follows a different flight 
path than IIIB during the launch and transition phases of flight. This flight path is 
predicted by the ship’s combat system so that the combat system can accurately direct the 
radar to “capture” the missile (establish communications). The software producing this 
prediction is the Missile Trajectory Estimator (MTE). In some cases, the differences 
between IIIA and IIIB may be significant enough to impact radar performance. At a 
minimum, the combat system needs to alter and/or analyze the MTE to ensure that it 
encompasses the boundaries of the IIIA flight profile. 

Both of these changes occurred after significant program “run” time. Therefore, 

both efforts experienced schedule delays and additional expense. Both changes also 

require coordination between the respective contractors so that system compatibility is 
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maintained. After significant delays (which were attributable to organizational difficulties 
described later in section D) the combat system contractor has begun perfonning the 
necessary analysis of the MTE. However, the C/S contractor has still not provided 
complete and up-to-date models of the radar or WCE and thus the JUWL developer 
continues development with added risk. It is unclear if the models do not exist, are not 
complete, or are not being provided for some other reason. 

C. INTEGRATION 

Langford and Hitchins make persuasive arguments that integration is most 
important part of SE development (see Chapter III). Integration produces emergence, 
which is Hitchins’ term for the phenomenon in which a system produces faster, 
expanded, or otherwise “better” system performance than the components of the system 
could achieve operating independently. 

This section will examine DDG-1000 missile integration in terms of Langford’s 
seven principles in integration. Annette Krygiel’s 1999 case study entitled Behind the 
Wizard’s Curtain: An Integration Environment for a System of Systems also provides a 
number of key integration insights gleaned from prior large-scale integration projects. We 
will also discuss other integration case studies that reinforce the critical nature of 
integration and illustrate the pitfalls of reducing integration to merely something done 
after “.. .analysis and design have taken place...” (Hyer et al. 1996, 315). 

1. Integration-Langford’s Principles 

Langford’s Seven Principles of Integration, listed in Appendix A, are an early 
feature in his text Engineering Systems Integration: Theory, Metrics, and Methods. They 
appear before he explains his conceptual construct of integration and serve to remind the 
reader that: 

Principles of integration extract insular thinking from the quagmire of 
confusion, help guide decisions based on the sound and the good of a 
particular situation, and present a logic that creates an air of confidence. In 
as much as the principles help others justify their actions, the mere fact of 
discussing and employing principles facilitates decision fitness and 
decision making throughout an organization (Howard and Matheson 
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1984), reinforces the teamness that inspires success, and provides a top- 

level perspective that retains purpose, objectivity, and planning prowess. 

(Langford 2012, 10) 

Langford’s Seven Principles are the Principles of Alignment, Partitioning, 
Induction, Limitation, Forethought, Planning, and Loss. While all of Langford’s 
principles apply to any integration activity, this paper will focus on those deemed most 
relevant to missile integration on DDG-1000. 

a. Principle One-Alignment 

Langford’s alignment principle states that alignment of strategies between the 
business enterprise, key stakeholders, and the project results in better outcomes for 
product development. He states “.. .knowing the needs of the project and how those needs 
are supported by the business enterprise and the key stakeholders is important in keeping 
high-level visibility with the decision makers...systems engineers place great importance 
on working with stakeholders to detennine requirements, verify that the work 
accomplished satisfies the requirements, and deliver to satisfy the user requirements” 
(Langford 2012, 11). For the DDG-1000 program in general, and missile integration in 
particular, strategies have not been aligned. 

The clearest example of misalignment is the fundamental disagreement 
concerning the appropriateness of a “use-as-is” decision for missile requirements 
discussed in Section B. The author believes that a use-as-is requirement is prima facie 
unrealistic; the ship’s missile launchers, combat system, and radar are all new 
development items. If there were no differences involved, then no integration would be 
needed. However, the SIPM clearly felt that similarities to existing systems (the APAR 
version of ESSM and SM) warranted the lower cost “use as is” decision; if no significant 
software or interface problems are uncovered before and during operational testing their 
opinion will be confirmed. However, history suggests that this will not be the case. 

In 1996, the Ariadne 5 rocket lost flight control immediately after launch and was 
completely destroyed. The root cause was found to be failure to integrate and test two 
software elements in the rocket’s inertial reference system (Madni 2012). In 1997, the 
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USS Yorktown suffered a complete failure of its “smart ship” system. The system was 
installed in 1996 as a completely automated way to control the engineering plant; the ship 
had to be towed to port after the failure. The problem was traced to inadequate testing of 
data interfaces; a zero inadvertently entered into a data field caused a “divide-by-zero” 
error which crashed the entire computer network (Madni 2012). The Airbus A320, an 
enonnous commercial aircraft project, was delayed by over two years (at a cost of 
$6 billion) because of a simple semantic error on a mechanical description document 
between a Gennan subcontractor delivering wiring harnesses and the French factory 
constructing the aircraft (Madni 2012). Other high profile examples can be found in 
NASA’s Hubble Space Telescope program; the Air Force’s Theatre Battle Management 
Core System (TBMCS); the F-lll and A-10 aircraft programs; and the Global Hawk 
UAV program (AFIT 2010). 

Misalignment can also stem from organizational differences and the associated 
differences in contract content and schedules. The responsibilities for producing DDG- 
1000 and its combat system are spread over three program offices and three prime 
contractors; coordination of effort is thus more difficult. Further discussion of 
organizational issues appears later in Section D. 

b. Principle Four-Limitation 

Langford’s fourth principle states that integration can only be successful to the 
same degree that the architecture is successful in capturing stakeholder requirements. 
DDG-1000 missile integration faces a significant problem because engineers and 
designers are developing systems to integrate with other systems that are likewise in 
development. Hence interfaces, standards, and performance are all subject to change. 
This makes a development program more difficult-although DDG-1000 is certainly not 
unique in this respect. The absence of clear requirements discussed in Section B also falls 
under this principle, as an architecture cannot be truly developed until a firm set of 
requirements is in place for the architecture to meet. 

However, a second key point Langford makes with the principle of limitation is 
the importance of the concept of operations (CONOP) in guiding architecture developers 
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and component designers. The CONOP is a critical document that must be kept current. 
In the absence of other, detailed specifications, it provides designers a frame of reference 
to plan their activities and is an invaluable tool for a design team (Langford 2012). The 
DDG-1000 AW CONOP has not been updated to reflect significant program changes. In 
particular, it does not reflect the removal of the VSR and the change from SM2 Block III- 
B to III-A. Given the absence of specific requirements, the out-of-date CONOP further 
constrains the development team because they do not have a reference document to refer 
to when conducting trade studies or planning for testing. 

c. Principle Five-Forethought 

Langford states that integration is a primary, key activity-not an afterthought 
considered as a result of development. The following quotes are illustrative of his view 
on the subject: 

Integration is a daily focus, with periodic updates to the integration plan. 
Integration is an explicit goal of acquisition... (Langford 2012, 19) 

...planning for integration alleviates problems that surface during 
integration (Langford 2012, 20). 

...often requirements are left unstated...at best, this technique of building 
systems is a guess at building objects so that performances are met...this 
guess-and-try again approach to integration is time-consuming and dollar- 
expensive. (Langford 2012, 20) 

DDG-1000 missile integration has fallen squarely into the trap of the “guess-and- 
try again” paradigm. 

2. Integration-Krygiel’s “Best Practices” 

A 1999 DOD case study report entitled Behind the Wizard’s Curtain: An 
Integration Environment for a System of Systems examined large scale system of systems 
integration in two projects: The Anny’s Task Force XXI (TF XXI) and the Defense 
Mapping Agency’s (DMA) Digital Production System (DPS). The DPS was intended to 
produce an end-to-end digital production system for all of the DMA’s mapping, charting 
and geodesy (MC&G) products (Krygiel 1999). TF XXI was an Army project born out of 
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Army Chief of Staff Gordon Sullivan’s efforts to fundamentally re-constitute the Army 
after the end of the Cold War. Sullivan believed the down-sized, post-Cold War Army 
would need to be expeditionary in nature and would need “...fundamental changes in 
every aspect of the Army, including structure, doctrine, capabilities, training, and tactics” 
(Krygiel 1999, 72). Such an expeditionary force would depend on a “digitized battlefield” 
with cutting edge information technology (IT) and command and control (C2) systems. 
TF XXI was tasked with conceptualizing, testing, and selecting the C2 and IT systems for 
the “Army after next” (Krygiel 1999, 74). 

The case study produced nine integration recommendations, similar to Langford’s 
seven principles. In fact, some of the recommendations are nearly identical. The 
most relevant recommendations will be discussed here; the entire list can be found in 
Appendix B. 


a. Lesson 1 

Lesson 1 states that some activities must occur before integration, including 
developing the system architecture, developing and testing the system constituents, and 
developing and testing all interfaces. Annette Krygiel, the author of the study, makes this 
observation when discussing “pre-integration” activities: 

The promise of plug-and-play is a seductive one...(t)his lesson serves to 
remind that verifying the individual constituent systems and interfaces and 
certifying them for architectural compliance are not activities which 
conclude the integration process but rather are necessary to begin it. The 
lesson is applicable to a SOS which is a “new start” or one which 
incorporates many legacy systems. (Krygiel 1999, 148) 

While there is a great deal of debate regarding the appropriateness of the term 
“System of Systems” in the greater SE community (see, for instance, Hitchins [2012] or 
Stuckenbruck [2008]), there is no doubt that the “use as is” requirements of the ESSM 
and SM missile have resulted in a false belief that integration is something that is done to 
conclude a project. Krygiel (like Langford) found that integration success is greatly 
improved by emphasizing integration needs early; failing to do so increases risk. 
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b. Lesson 4 

Lesson 4 states “...To integrate all the systems of a SoS, plan for substantial 
difficulties and significant time and resources” (Krygiel 1999, 158). The report goes on: 

This lesson rejects outright the assumption of plug-and-play, even while 
presupposing that the appropriate testing of individual systems and their 
interfaces has occurred. It provides a counter-assumption for planning 
purposes based on current experience—that the integration of a SOS is a 
strenuous undertaking. (Krygiel 1999, 159) 

This is a clear rejection of what are often tenned “overly ambitious schedules.” 
Even if appropriate pre-integration activities have occurred, managers should still expect 
to expend significant time and resources on performing a thorough integration effort. The 
resource needs increase with the complexity of the systems to be integrated. 

The JUWL integration plan is very ambitious. The current schedule allows each 
missile variant one three-to-four month period for “ground-based” integration with the 
C/S prior to at-sea flight testing. At this time, the ground integration tests will be 
performed with a version of the C/S software that will be different than the flight test 
version. Successful flight tests will therefore depend a great deal on the type and extent of 
the differences in the final two DDG-1000 C/S software versions and the base APAR 
software that has directed JUWL development. As discussed above, the lack of radar and 
WCE models has forced the JUWL developers to use the original APAR/ICWI software 
as a basis for modeling and component testing. 

Furthermore, the testing plan reflects an intention to “leverage” the results of 
ESSM (the first missile to conduct integration testing) into the SM integration activity. 
The essentially means that SM will not conduct the same “suite” of integration tests and 
activities that ESSM does on the assumption that what works for ESSM, given the 
common data link, will work for SM. While this is certainly possible, it does not allow 
for the resolution of any problems that may be encountered. In addition, the CVN-78 
program is planning on “leveraging” from DDG-lOOO’s ESSM integration, despite the 
fact that the DBR and C/S implemented on CVN-78 will not be the same as that 
implemented on DDG-1000. The compressed, aggressive integration schedule must be 
considered a risk in light of Krygiel’s Lesson 4. 
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c. Lesson 7 

Lesson 7 contains the following recommendations: 

Certain common processes and common infrastructure in the integration 
environment are essential to manage a SOS integration successfully. These 
include the following...an Engineering Board with responsibility and 
authority for identification and resolution of SOS issues and discrepancies, 
including the assignment of responsibility for correction...establishment 
of processes (and the automated means) for identification of SOS issues 
and discrepancies, their disposition, tracking, and resolution, under the 
management of the Engineering Board...a formal build, verification, and 
re-integration process for changes.... (Krygiel 1999, 167-168) 

The lack of a consistent, effective mechanism to resolve technical issues between 
the C/S and missile programs has hindered the JUWL effort. The missile program has 
recognized many of the potential technical and integration risks described in this thesis 
(IWS3 2012). A missile integration working group (MIWG) was established to analyze 
technical problems and assign actions to resolve those problems. The MIWG was 
disbanded and restarted several times over the course of the program; the last disbanding 
occurred after the 2010 restructuring of the entire DDG-1000 program, and the 
subsequent deletion of integration funding. This was a particularly unfortunate time to 
eliminate the group as other changes from the restructuring, deletion of VSR, for 
example, drove changes into the combat system. 

Even if the MIWG and its adjunct group, the Missile Integration Change Control 
Board or MICCB, had remained in operation from 2010-2012, the “use-as-is” 
requirement decision resulted in statements of work that precluded design changes in 
legacy hardware. Such work was deemed “out of scope” in contractual terms. Therefore, 
even if an integration problem is identified, such as the MTE issue described earlier, it is 
difficult for the program offices to enable the contractors to perform the necessary 
analysis and/or corrective action. These delays only exacerbate the potential for last 
minute “show stoppers” to cause significant cost increases and schedule delays for DDG- 
1000 . 
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3. Integration-Other Best Practices 

Johns Hopkins University’s Advanced Physics Laboratory (JHU APL) assisted 
the NATO Sea Sparrow Program Office (NSPO) with planning and conducting the 
integration of ESSM with the varying combat systems and ships of the Sea Sparrow 
consortium nations (Hyer et al. 1996). The development effort began in the mid-1990s 
and ESSM began operational testing in 2002. 

One of the key integration steps taken early in the ESSM development effort was 
the establishment of a Systems Integration IPT. The SI IPT interfaced directly with the 
ESSM Integration IPT (see Figure 30. ). The ESSM Integration IPT was part of the prime 
contractor’s IPPD structure and oversaw numerous component IPTs as they performed 
their design activities-engineering analyses, trade studies, and so on. The SI IPT 
provided a forum for the various consortium navies to bring forward various issues 
directly to the design team. This was a critical step, as ESSM was to be operable with six 
different combat systems on 13 different classes of warship while also maintaining some 
capacity for future expansions (Hyer et al. 1996, 319). 


ESSM 

Integration 


Systems 

Integration 


Component IPTs 

Ship eng neerng and 
ritegration activities 


Dooa 


Figure 30. ESSM Development IPTs (from Hyer et al. 1996, 321) 


The arrangement was intended to allow the various nations an opportunity to pursue 
their individual C/S needs and also allowed the program to identify and develop common 
interfaces where possible. It also gave the opportunity to influence design in order to 
mitigate identified configuration issues (Hyer et al. 1996). This type of arrangement, as 
noted in Section (2), has been lacking for the DDG-1000 missile integration effort. 
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The Defense Acquisition Guidebook discussion of SE (found in Chapter IV, 
emphasis added) states the following: 

A system should not be acquired in isolation from other systems with 
which it associates in the operational environment .. .to that end, the 
Program Manager and Systems Engineer should define intersystem 
interfaces...the Program Manager and Systems Engineer should also 
actively pursue Memoranda of Agreement or Memoranda of 
Understanding (MOA/MOU) with companion programs regarding 
interfaces, data exchanges, and advance notices of changes, 
interdependencies and schedule (timing) that may affect either program. 

These agreements are... a means of mitigating the inherent risk in 
planning to deliver a capability to an anticipated future technical baseline 
when there is uncertainty that the other programs are able to maintain 
schedule and have adequate resources to deploy the capabilities as 
planned. (DAG 2013, 156) 

The DDG-1000 missile integration effort does have MOAs in place, but as 
described earlier, coordination has not always been timely or productive. 

D. ORGANIZATION 

Integration of large, complex systems is not easy. Establishing the correct 
engineering organization is critical for success (Stuckenbruck 2008). Many of the 
concerns that DDG-1000 missile development has faced are not unique-all major 
acquisition programs face the same challenges. The DOD routinely institutes new or 
improved processes or organizational structures in an attempt to improve the outcomes of 
the DAS. 

Weapon system acquisition for the Navy had traditionally been tied to platform 
development. Once the weapon system was operational, the program office shifted into a 
primarily sustainment mode, with the possibility of additional development work to field 
weapon improvements. In 2002, PEO IWS was organized for the specific purpose of 
consolidating Navy combat system acquisition from a vertical, platform-centric approach 
to a horizontal, functional approach (Mink 2006). The reorganization was in concert with 
a new open architecture (OA) acquisition approach for combat systems. The new OA 
philosophy was a “...multifaceted business and technical strategy for acquiring and 
maintaining National Security Systems (NSS) as interoperable systems that adopt and 
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exploit open-system design principles and architecture” (Emery 2010, 2). The express 
goal of the reorganization was to reduce costs (Kime 2004; Syring 2012). The cost 
savings were to be realized from “cross program efficiencies...multi-year procurement 
potential...challenging fixed and support costs...(and) maximizing leverage across 
product lines and programs” (Deegan 2012). 

Certain offices in PEO IWS are specifically established as Systems Integration 
Program Managers (SIPM); Figure 31 shows the weapon acquisition process as 
envisioned during the reorganization of PEO. 


Product Line Engineering 


Product 

Development 


System Integration 
and Test 



Figure 31. PEO IWS Notional Acquisition (from Emery 2010) 

Several challenges remain for PEO IWS to achieve the type of consolidated 
control that Assistant Secretary of the Navy for Research, Development, and Acquisitions 
(ASN RDA) John Young envisioned at the time PEO IWS was created. 

First, and perhaps most important, is the fact that funding streams for various 
projects (including JUWL) are not managed by PEO IWS. This clearly contradicts the 
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intended process shown in Figure 31. Shipbuilding and Conversion, Navy (SCN) funds 
pay for the development and construction of all naval vessels; such funds are controlled 
by the ship program office. JUWL (for example) is a development effort tied to a new 
class of ship; hence SCN funds pay for program activities. This divide between weapon 
development and funding inhibits the stated IWS goal of reducing the number of 
baselines in the weapons inventory and creation of over-arching warfare systems-because 
IWS cannot pay for them directly (Mink 2006). “Legacy” weapon programs are funded 
via Other Procurement, Navy (OPN) allocations and do not face such challenges. 

The inconsistency in funding is indicative of a more general problem concerning 
authority, responsibility, and the delineation of roles and responsibilities. Different 
program managers (PEO Ships, PEO IWS, PEO Carriers, and so on) will clearly have 
different opinions on programmatic risk and different priorities in program execution. 
Memorandums of Agreement (MOAs) are often used to define roles and responsibilities, 
but they are by no means a guarantee of success. For example, ship program managers 
(SPM) often maintain configuration control for any system being installed on the hull, 
whether it is combat system-related or not (Mink 2006). Some SPMs moved their combat 
system related staff to the IWS equivalent office, while others did not. Therefore, some 
SE tasks and organizations are undoubtedly duplicated at great cost. Failed coordination 
of other activities can have operational consequences: 

An example of uncoordinated ECPs can be seen when coordinating 
changes to the Warfare System Interface Diagrams (WSID). They depict 
all warfare system elements and their interconnectivities for each ship and 
are used to maintain ship warfare system configurations. In the past, 
requested WSID changes to aircraft carriers, amphibious, auxiliary, Coast 
Guard, and land-based test sites (LBTS) have often bypassed the PEO 
IWS Warfare System Engineers responsible for system engineering 
coordination for these platforms. These uncoordinated changes, when 
implemented aboard ships, have resulted in warfare systems having 
impaired operability. Fixing these unexpected integration problems 
consumes resources that are often unbudgeted.... (Mink 2006) 

IWS 9 has the role of System Integration Program Manager (SIPM) for surface 
weapons and is “dual-hatted” as the program manager for the development of the MFR. 
The other IWS office codes involved in DDG-1000 missile development (3A) and 
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eventually missile production (3A and 3D) can be seen as fulfilling subcontractor roles to 
IWS 9 and PMS 500. As stated, some IWS program managers (cast in the role of 
“subcontractors” to the overarching ship program manager) do not control their funding. 
General communications between the various offices and their respective contractors are 
hampered by the multitude of SOWs, funding available to support technical exchanges, 
and general procedural cumbersomeness. Methods to address engineering change 
proposals (ECPs) vary from one program to another and can be repetitive, costly, or more 
seriously, not well established. 

As with many organizational improvements and “comprehensive” changes, 
failure to enact the entire bundle of improvements can result in less improvement than 
expected. In some cases, incomplete changes could produce worse results than the 
original configuration. Critics of the establishment of PEO IWS highlighted concerns 
over disrupting successful programs, the size and complexity of the effort, and an over¬ 
stretched span of control for IWS managers (Kime 2004). The last eleven years may have 
proven the critics to be at least partially correct. 

While the JUWL effort for DDG-1000 does not use the Lead Systems Integrator 
(LSI) concept, similarities do exist between the LSI concept and the current matrix 
organization of PEO IWS. The matrix organization of PEO IWS resembles the LSI 
concept in the fact that the lead systems integrator is not the same organization 
responsible for managing all of the constituent systems to be integrated. The 
organizational structure for DDG-1000 integration encounters many of the same 
problems that LSI programs encountered which are described below. 

In essence, the LSI concept involves hiring a firm to conduct the system 
development and program management activities that the government traditionally 
performs (Gully 2003). It was first employed in the Anny’s Future Combat System (FCS) 
program. The FCS was intended to develop a SoS that would meet the Anny’s 
modernization needs well into the 21st century. The original FCS SoS architecture 
consisted of nine manned ground vehicles, four unmanned aerial vehicles, four unmanned 
ground vehicles, and numerous unmanned ground sensors; all “networked” together by 
multiple communications and C4ISR systems (Gully 2003). 
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The Army selected the LSI approach for the FCS because it felt it did not have the 
expertise to manage the development and integration of over 20 separate supporting 
programs. The Army also felt it did not have the time to develop such an organization 
because of FCS’s aggressive timeline and the cumbersome federal personnel system 
(Flood and Richard 2006). Hence the Army contracted an industry team to perfonn the 
LSI role. Boeing and Science Applications International Corporation (SAIC) were 
selected as the LSI. 

The LSI arrangement, while theoretically sound, encountered immediate 
problems. Most problems can be grouped into two categories: “cultural” and 
“procedural.” The cultural problems arose from the new duties and responsibilities 
assigned to participants in the system. Government program personnel, used to authority 
and responsibility, were relegated to oversight tasks. This often led to adversarial or 
strained relations when the LSI made programmatic decisions counter to the program 
office’s desires. The LSI, in turn, felt that the Army was not prioritizing the FCS in 
comparison to other programs and also felt that many in the Army opposed the entire 
network-centric concept. This doubtless led the LSI to discount the Army’s opinions on 
the many issues raised in the early stages of concept development (Flood and Richard 
2006). 

Relations between the LSI and the various subcontractors were also strained, as 
many “subs” believed the LSI was ignoring their concerns or otherwise maneuvering to 
win future production and development contracts for architecture components under 
consideration (Flood and Richard 2006, 364). Congress balked at the loss of monetary 
control over FCS-the LSI effort was a single program element (PE) in the Army budget 
and thus the LSI had much greater control over funding than a traditional program 
manager. Congress was also concerned with the incentive fee structure of the contract; 
various reports pointed out that the LSI could receive some or all of its substantial 
incentive fees even if the Army never took delivery of a single FCS component (GAO 
2007). 
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Procedural problems also haunted the FCS program. Program participants in both 
industry and government universally stated that the FCS contracts were not specific 
enough to give the government a means to enforce its oversight role. There were no 
mechanisms in place to resolve requirements disagreements, for example, and the LSI 
made these programmatic decisions by default. The processes in place for integration and 
lower-level requirement coordination were slow and cumbersome. Many subcontractors 
and government personnel felt that their concerns were “buried” by the LSI, or at the 
least were not heard at the appropriate level (Flood and Richard 2006, 367). Indeed, an 
industry “whistle blower” resorted to posting video explanations of his concerns with the 
program on the Internet when he felt he could not gain traction with anyone in the LSI 
hierarchy (Gansler 2009). 

The FCS was the target of considerable Congressional scrutiny and was re¬ 
organized three separate times before finally being cancelled in 2009; the “subsystems” 
that had not been cancelled were relegated to various other program offices. 

The FCS is not the only example of the LSI concept “gone wrong.” The Coast 
Guard’s “Deepwater” program was a similar, large scale development designed to 
produce a networked SoS of cutters, patrol boats, aircraft, and unmanned vehicles. The 
LSI in this case was a joint effort of Lockheed Martin and Northrop Grumman. The first 
contract was awarded in 2002. By 2007, the Coast Guard took over the LSI role because 
of perceived poor performance, delays, and cost overruns. In subsequent years, 
significant components of the original SoS were cancelled, including the various 
unmanned aerial vehicles and several of the proposed surface ships and craft. The 
Deepwater project, much like FCS, was finally cancelled in 2012 with remaining 
development assigned to specific program offices (Lipowicz 2013). 

The FCS and Deepwater programs were so poorly regarded that in 2008 Congress 
passed legislation prohibiting any future acquisition program from utilizing the LSI 
approach (Gansler 2009). 

The funding and communication difficulties experienced by PEO IWS when 
working with other program executive offices is similar to those experienced by FCS and 
Deepwater. PEO IWS features an internal matrix organization that is specifically 
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designed, like any matrix organization, to balance the needs between integration and 
specialization (Stuckenbruck 2008, 211). However, implementing an effective matrix 
requires consistent effort towards fostering effective management interfaces and a great 
deal of planning and effort (Linnebuck 1988). Unfortunately, PEO IWS does not merely 
have to manage its internal organization; it must also interface with program elements 
beyond its control. 

E. SUMMARY 

Missile integration for DDG-1000 is a seemingly straightforward technical effort. 
However, in the context of systems engineering, “straightforward” does not necessarily 
mean “easy.” For DDG-1000, missile integration has been challenging because of 
requirement, integration, and organizational issues. 

Major elements of the program did not agree on the importance of establishing 
new top level requirements for DDG-lOOO’s intended missiles. Instead the decision was 
made to use legacy missile requirements for every aspect of the missile except the new 
data link. This introduced substantial risk because the unspecified operational needs and 
unknown hull environments of DDG-1000 may not be satisfied by legacy missile 
specifications. 

Integration has also been challenging. Despite substantial evidence from prior 
programs and over-arching guidance from the DOD, integration appears to be an 
afterthought for many programs, including the missile components of the DDG-1000 
program. Each missile variant has approximately three months allotted to conduct all of 
the integration activities needed with the radar and combat system before the missiles are 
scheduled for their first test firings. Scheduling initial integration activities so late in a 
program increases cost and schedule risk because unanticipated problems will be harder 
to correct. Changing requirements late in the program also increases risk, for similar 
reasons. The program must also have a robust method for assessing and rectifying 
technical integration challenges that are identified by designers. 
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Organization structures can influence both requirement and integration 
challenges. In the case of PEO IWS, its matrix organization would be ideal for this sort of 
development effort if it was also funded adequately to perform its integration manager 
role and had complete control of the development funds dedicated to its programs. Any 
large scale integration effort faces challenges in communication and coordination; the 
establishment of a robust “Systems IPT” or engineering change control board is critical to 
resolving technical issues as they arise. 
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VI. FINDINGS, CONCLUSIONS AND RECOMMENDATIONS 


A. FINDINGS AND CONCLUSIONS 

The strategic situation that gave rise to the early DDG-1000 concept of a land- 
attack destroyer changed rapidly as the United States reacted to the post-Cold War world. 
The first reaction to the collapse of the Soviet Union, when combined with the near- 
simultaneous technological triumph of the First Gulf War, produced the “Revolution in 
Military Affairs” paradigm. The RMA emphasized technical dominance and the DDG- 
1000 was deliberately intended to feature “next generation” technology in every aspect of 
the ship. This was in direct contrast to the Navy’s longstanding experience of adding one 
or two emerging technologies to known hull forms-perhaps best exemplified by the 
commonality and incremental growth between the FFG-7, DD-963, CG-47, and DDG-51 
classes. Ironically, the Navy submarine force had just experienced the perils of inserting 
too many new technologies (and the concomitant risks and cost) into its next generation 
platform (the Seawolf class); many of the issues that affected Seawolf are replicated in 
Zumwalt. 

The changing strategic situation resulted in requirement changes and cost growth 
(as the numbers of intended ships were repeatedly reduced). The most consequential 
change for missile development was the deletion of the VSR from the ship. This, in turn, 
drove changes into the MFR-particularly in the areas of radar timeline and, potentially, 
the concept of operations. The impacts of those changes have yet to be fully identified 
and tested. 

The drive to use existing missiles in DDG-1000 led to a “use as is” decision 
regarding top-level missile requirements for the ship. Only new requirements for a data 
link were generated. All other missile requirements (performance, safety, mechanical and 
electrical interfaces, and so on) remain unchanged from the missiles’ Aegis system 
requirements. The “use as is” decision does not change the fact that the DDG-1000 
environment will not be identical to an Aegis-equipped vessel. DDG-1000 will have a 
new radar, new combat system, new launcher, new hull form, and new mission-all 
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distinct from legacy Aegis ships. Therefore, the program accepted integration and 
(ultimately) performance risk by not allowing engineers to identify and address potential 
technical risks early. These risks were compounded by scheduling a late, aggressive 
integration and test schedule that counted on “leveraging” successful test results between 
ESSM and SM. This plan will only work if the initial tests are, indeed, successful. 

Organizational obstacles exacerbated funding, requirement and engineering 
difficulties. All development items for DDG-1000, including the DBR and JUWL, are 
funded via SCN appropriations. The missile integration program managers do not have 
control of this funding and are at the mercy of someone else’s schedules, contract criteria, 
and priorities. The 2011 shut-down and re-start of the JUWL development program is a 
prime example of the consequences of a fractured chain of command and funding 
process. This situation is precisely what the 2002 reorganization of the PEO structure was 
intended to rectify-but that intended system has not been fully realized. 

Organizational structure complicates integration and engineering cooperation. 
There has not been a consistent, empowered government decision-making body capable 
of resolving technical issues identified in the respective programs. Therefore, technical 
risks are continually “carried forward” instead of being resolved at the earliest possible 
stage. 

In the introduction, two overarching question were raised concerning missile 
development for the DDG-1000 program. DDG-1000 has yet to be launched and no 
missiles have been fired from the ship. Therefore, it may be premature to definitively 
state any lessons learned from failures or successes. However, the thesis has clearly 
identified risks that were accepted by the program that appear to be unwarranted given 
prior case studies and systems engineering standards. The following table summarizes 
those risks and potential impacts to the program. 
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Table 5. Integration Issues and Consequences 


Issue 

Potential Consequence 

No top level requirements 

Failure to meet perfonnance needs; safety risks 

Late requirement changes 

Costly rework, schedule delays 

“Use as is” decision 

Late identification of integration problems, 

inadequate architecture design 

Poor organizational construct 

Poor engineering change and integration 

control, slow response to new issues 


All of the issues have been catalogued and discussed in academic sources, 
systems engineering documents, and government publications. The results of the thesis 
verify the guidelines put forth by Langford, Krygiel, and others. Numerous briefings and 
studies highlight the recurring themes of inadequate and changing requirements, poor 
organizational design, and underestimates of integration cost and time requirements. Why 
DOD programs continue to repeat errors of this type is a question that will continue to 
face program managers and government executives and deserves continuing examination. 

B. RECOMMENDATIONS 

The DDG-1000 program in general, and missile integration for DDG-1000 in 
particular, face numerous challenges that seem to be endemic to the defense acquisition 
system. All of the issues described in this paper have affected numerous development 
projects in not only all four services of the DOD, but also in other government projects 
and even in commercial industry. 

Congress, the Executive branch, and the DOD have taken steps to rectify these 
systemic problems, but the complexity of the systems being acquired and the diverse, 
interwoven organizations needed to conduct the acquisition process continues to stymie 
reform efforts. These problems are likely to continue, and possibly worsen, as the DOD 
likely faces near-stagnant growth or even a reduction in future budgets. Integration is 
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commonly one of the first areas to see funding reduced in a project. Many managers still 
consider it a “nice to have” or consider integration another name for testing (NDIA 
2003). 

It is critical that Congress, the president, and the DOD not abandon efforts to 
improve the acquisition system. The following recommendations, based on the principles 
and lessons learned described earlier, would help mitigate the issues discussed. 

First, the DOD must continue to emphasize and enable the application of systems 
engineering early in the acquisition cycle. Systems engineering as a discipline is intended 
to resolve many of the engineering development challenges described in this paper. Clear 
definition of user needs, thorough examination of alternate means to meet needs, and 
complete translation of needs into clear requirements are the hallmarks of the early steps 
of systems engineering. This recommendation is in keeping with Langford’s principle of 
emphasizing integration activities early. Integration is what provides the benefit of the 
system, and thus it should be emphasized continuously. The benefits of applying systems 
engineering early have been highlighted in numerous studies, including the IEEE study 
described in Chapter IV (Elm and Goldenson 2012). 

For JUWL, a critical early decision to use ESSM and SM “as is” (with the 
exception of the new X-band data link) produced substantial risk that has been carried 
forward through the program. Such a decision would likely not have been made under 
scrutiny from a vigorous SE analysis. The missiles are required to interact with a great 
deal more than just the radar system after launch. They must be compatible with their 
mechanical and electrical environment. Missile performance must meet the perfonnance 
requirements explicitly established for the combat system or derived from the CONOP. 
An SE analysis would also have examined the expected life cycle of the missiles and 
expected number to be produced, and may have identified the SM-2 Block III-B 
inventory issue that led to the 2012 decision to change from Block III-B to Block III-A. 

Application of systems thinking and the SE process can avoid situations such as 
the one DDG-1000 now faces. The DOD has acknowledged this fact for over twenty 
years and has taken significant steps to install systems engineering rigor into weapon 
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acquisition. One avenue of further research suggested by this paper is an examination of 
why such steps have not produced more significant improvements in weapon acquisition 
outcomes. A quick comparison of the NDIA’s top five SE issues from 2003 to 2013 
shows consistent themes of poor requirement formulation, poor change control, 
inadequate user involvement, and late-changing requirements (NDIA 2003; NDIA 2008; 
NDIA 2013). There is also evidence that acquisition programs do not perform the 
activities they are directed to implement (Masters 2008, 8). The 2010 QDR described 
four issues facing the DOD that require “imperative” reforms; one of those areas was 
acquisition (OSD 2010). The acquisition concerns were further described as: 

First, the requirements for new systems are too often set at the far limit of 
current technological boundaries...(T)he Department and the nation can 
no longer afford the quixotic pursuit of high-tech perfection that incurs 
unacceptable cost and risk. Nor can the Department afford to chase 
requirements that shift or continue to increase throughout a program’s life 
cycle... 

Second, the Pentagon’s acquisition workforce has been allowed to 
atrophy, exacerbating a decline in the critical skills necessary for effective 
oversight. For example, over the past ten years, the Department’s 
contractual obligations have nearly tripled while our acquisition workforce 
fell by more than 10 percent...(T)here remains an urgent need for 
technically trained personnel—cost estimators, systems engineers, and 
acquisition managers—to conduct effective oversight... 

Third, our system of defining requirements and developing capability too 
often encourages reliance on overly optimistic cost estimates... In order 
for the Pentagon to produce weapons systems efficiently, it is critical to 
have budget stability—but it is impossible to attain such stability in 
DOD’s modernization budgets if we continue to underestimate the cost of 
such systems from the start...(T)here are too many programs under way. 

We cannot afford everything we might desire; therefore, in the future, the 
Department must balance capability portfolios to better align with budget 
constraints and operational needs, based on priorities assigned to 
warfighter capabilities...(OSD 2010, 76) 

These are the same problems identified in a host of previous studies. Why have 
earlier improvements efforts failed? Identification of underlying issues that are stymying 
the efforts of OASD-SE and others could contribute to better acquisition performance in 
the future. 
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Second, programs must require a thorough systems architecture analysis and 
requirements flowdown for legacy systems integrated with new systems. This 
recommendation is an amplification of a portion of the early SE process recommended 
above. The emphasis is necessary because the use of a legacy system as part of a new 
system raises additional opportunities for a loss of SE rigor. The requirements flowdown 
process, by which higher system level requirements are examined and assigned to lower 
level system components, is a key activity in early systems engineering. It ensures that all 
requirements are accounted for in the system design (NASA 2007). It also provides an 
opportunity to examine the adequacy of the requirements. If the requirement does not 
clearly state the need to be met then the requirement will not be easily assigned to a 
subsystem. This mismatch indicates a need to revise or rework the requirement 
(Blanchard and Fabrycky 1998). 

As we have discussed, program offices face perennial difficulties in maintaining 
cost and schedule targets. Incorporation of a legacy system, which in theory was already 
subjected to a rigorous requirements analysis, gives rise to a temptation to save time and 
money by not perfonning a thorough analysis of the legacy system in its new application. 
Such a thought process is evident when considering the fundamental disagreement 
between the responsible program offices on the necessity of such requirements for 
ESSM/SM/JUWL. The disagreement points to a need to develop an informed analysis of 
the issue. 

The systems engineering “method” tells us that requirements must be analyzed 
and flowed down in any development project, even one utilizing existing technology 
(Langford 2012; Blanchard and Fabrycky 1998). Even if one allows that such an analysis 
was done for DDG-1000 and JUWL, the analysis did not go far enough into the details of 
integration. It stopped at a high level and claimed that “use as is” requirements were 
sufficient. 

Previous case studies have highlighted the difficulty of integrating even when 

such an analysis has been performed—programs must be prepared to find unanticipated 

integration issues (Krygiel 1999, Langford 2012). Adapting a legacy system for 

modification and introduction into a new system cannot be an excuse to forego the 

96 



critical initial steps of systems engineering, even if the program is “leveraging” the 
benefits of integrating a legacy system. As Krygiel noted in her study, “plug-and-play” 
can be a seductive notion that all too often fails to deliver on its promises. 

On a related note, we should consider the logical implications of using legacy 
weapons with new sensor systems (or vice versa). Consider that DDG-1000 was clearly 
intended to produce substantial performance improvements in all warfare areas in 
comparison to the existing Aegis system. The DBR was intended to track more targets 
with greater precision, engage more targets simultaneously, and so on. Legacy weapons 
(SM and ESSM) have performance envelopes traced to their requirements when used 
with legacy sensors. If we are developing a new sensor to expand our sensor performance 
envelope, have we done analysis to prove that our legacy weapons have a comparable 
expansion of their performance margin? In other words, DBR may be a significant 
improvement from Aegis—but such improvements may not be realized without 
concurrent weapon advancement. Again, early application of the SE process should 
answer these questions. Furthermore, we should consider the necessity for deploying a 
next-generation air defense system on a platfonn originally intended for a primarily land 
attack role. Would it have been feasible to deploy DDG-1000 with the Aegis system and 
save the DBR development for the CG-X? Such a plan would have been in keeping with 
the Navy’s practice of deploying only a few new technologies on each new warfare 
platfonn. 

Third, place all weapon system development funding under the control of PEO- 
IWS. The 2003 NAVSEA reorganization of its PEO structure was intended to place all 
weapon system acquisition in the control of the newly formed PEO IWS organization 
(Kime 2004; Mink 2006). This has not happened in all cases. The vagaries of the PPBE 
system, the Congressional budgeting process (and all of its political influences), and 
various statutes regarding federal outlays all combine to produce a fractured funding 
system. In the case of JUWL, funding flows from PMS-500, the program office 
responsible for overall DDG-1000 ship procurement. Tying weapons component 
development to new ship construction (particularly new class construction) increases the 
organizational difficulties described in Chapter V. Additional layers of coordination and 
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approval result in increased delays. The responsibility to plan development, budget for 
development, and execute to that budget should reside with program manager closest to 
the effort. A corollary to this recommendation is the need to adequately fund and staff the 
integration manager of the project. The integration manager has the most critical piece of 
the development effort, and should be the driver of the development effort (even if it 
must cross program office boundaries). This step would also allow the integration 
manager to adequately fund the engineering change control board or integration IPT as 
described by Hyer et al. (2006) and Krygiel (1999). It would also allow the weapon 
program office to organize the change process to reflect the process used in other weapon 
programs rather than adopting the hull-centered ShipMain and SPM process (Mink 2006, 
37). 

The great success of the Aegis weapon system is contributable in great measure to 
the fact that Admiral Meyer and his staff were the single focus for all aspects of the 
program—not only sensor, weapon, and doctrine development but also logistics planning, 
maintenance support, and so on. Evidence of this can be seen in the fact that when 
portions of the program were removed from this “central” control program performance 
suffered (LaPointe 2013). The most noticeable effect was worsening material readiness of 
Aegis combat systems and deteriorating levels of expertise; however Aegis software 
improvements to support BMD also suffered delays and previously unseen integration 
issues (Harvey 2012). The acquisition system must reflect the military adage that states 
that authority must be commensurate with responsibility. 

C. FINAL THOUGHTS 

All of the recommendations listed above, and many other efforts already 
underway in the DOD to “fix” the acquisition system, require time and money. Given the 
fact that budgets will likely shrink or stagnate over the next decade, one could be 
pessimistic about the chances of success even if we accept the necessity of the corrective 
actions. Despite the general perception of waste and failure in acquisitions, there have 
been successful programs in recent years. The Virginia-class submarine and the MRAP 
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program come to mind. It does seem that success has become the exception, however, 
and the DOD (or perhaps more accurately the nation) cannot maintain the status quo. 

Removing the government from the management role (as in the Army’s FCS and 
the Coast Guard’s Deepwater project) is not the answer. Instead, emphasis should be 
placed on fully realizing the many initiatives implemented in the past. For example, if the 
Navy intends PEO IWS to develop combat systems via an open architecture model that 
can reduce inefficiencies and improve commonality, it should place all funding for 
weapon development, sustainment, and improvement under the IWS umbrella. PEO IWS 
is also a logical home for all technical and risk decisions to be made concerning both new 
and fielded weapons. This would have removed many of the difficulties faced by the 
JUWL program, particularly as they relate to integration. The DOD knows it must force 
systems engineering rigor into the early phases of acquisition-recent emphasis on early 
technical reviews and the creation of Configuration Steering Boards (CSB) for ACAT I 
programs affirm this—and those efforts must continue. 

The Navy has consolidated authority in other programs. The Navy nuclear power 
program and the Aegis combat system program have produced robust systems that have 
performed at a consistently high level for many years. Both of these programs had strong 
leadership, but they were also given all the tools necessary to meet their goals. Perhaps it 
is time to establish this consolidated control mentality into all weapons system 
acquisition programs. 
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APPENDIX A. LANGFORD’S SEVEN PRINCIPLES 


1. Principle of Alignment 

Alignment of strategies for the business enterprise, the key stakeholders, and the project 
results in better outcomes for product or service development. 

2. Principle of Partitioning 

Partitioning of objects can create tractable problems to solve if and only if boundary 
contiguity is achieved. 

3. Principle of Induction 

Inductive reasoning should guide integration management and recursive thinking. 

4. Principle of Limitation 

Integration is only as good as architecture captures stakeholder requirements. 

5. Principle of Forethought 

Integration is a primary, key activity, not an afterthought considered as the result of 
development. 

6. Principle of Planning 

Integration planning is predicated on pattern scheduling (lowest impact on budget), 
network scheduling (determinable impact on budget), and ad hoc scheduling 
(undetennined impact on budget). 

7. Principle of Loss 

When two objects are integrated, both objects give up some measure of autonomous 
behavior. 
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APPENDIX B. INTEGRATION LESSONS LEARNED FROM 
“BEHIND THE WIZARD’S CURTAIN” 


Lesson 1 

Certain activities should precede a SOS integration. These include: 
defining the SOS architecture; 
developing and testing the individual system 
constituents of the SOS; 

developing and testing the interfaces between and among the individual systems 
of the SOS; 

independently certifying compliance with the SOS architecture. 

Lesson 2 

Use early, incremental, and iterative integration to achieve a SOS. 

Lesson 3 

The testing strategy for the integration of a SOS requires: 

an agreed-to plan and process for testing, based on a risk assessment; 

a suite of activities representative of the operational requirements of the 
mission the SOS supports; 

the exercising of a full spectrum of the SOS activities (end-to-end) by 
operators, using the actual constituent systems of the SOS or at least a core 
SOS. 

Lesson 4 

To integrate all the systems of a SOS, plan for substantial difficulties and 
significant time and resources. 

Lesson 5 


The use of a single facility with an environment of people, processes, and 
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Infrastructure substantially facilitates the integration of a SOS from individual 
systems. 

Lesson 6 

The process for SOS integration should overtly address the leadership of the 
integration as follows: 

an on-site acquisition leader empowered for the integration of the SOS and 
an on-site leader empowered for the operational community; 

supported by a SOS cadre with sufficient resources and authority; 

supported by participants who manage, develop, and operate the 
constituent systems of the SOS. 

Lesson 7 

Certain common processes and common infrastructure in the integration 
environment are essential to manage a SOS integration successfully. These include the 
following: 

an Engineering Board with responsibility and authority for identification and 
resolution of SOS issues and discrepancies, including the assignment of 
responsibility for correction; 

establishment of processes (and the automated means) for identification of SOS 
issues and discrepancies, their disposition, tracking, and resolution, under the 
management of the Engineering Board; 

automated support for the tracking and tracing of SOS operational requirements; 

configuration management and control of the hardware and software baselines of 
the systems of the SOS by the integration leadership, supported with: 

automated means for identifying and controlling the baselines and 
subsequent changes; 

a formal build, verification, and re-integration process for changes; 
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a robust communications infrastructure linking the teams internal to the 
integration environment and their external counterparts; 

an office automation environment to support the integration’s 
administrative processes as well as to support interpersonal processing and 

communications for the participants. 

Lesson 8 

Certain common processes and infrastructure in the SOS integration environment 
promote effectiveness and efficiencies. These include: 

daily planning and scheduling of resources (people, equipment, facilities) 
for integration events with contingency plans and schedules readily 
available; 

timely dissemination of information pertinent to each integration event, 
such as test status, equipment availability, and results; 

daily status meetings, with results immediately available. 

Lesson 9 

Prototyping a SOS can provide early insight into operational requirements and 
into the SOS systems architecture. 


105 



THIS PAGE INTENTIONALLY LEFT BLANK 


106 



LIST OF REFERENCES 


Air Force Institute of Technology. 2010. “Synopsis of the Learning Principles-Systems 
Engineering Case Studies.” Air Force Center for Systems Engineering, Wright- 
Patterson Air Force Base, Ohio. 

Al-Rashid, Yasser. 2009. “Active Phased Array Radar Systems.” Presentation to the 
Multifunction Phased Array Radar System Symposium, (17-19 November), 
National Weather Center, Norman OK. Downloaded June 2013 from 
http://www.ofcm.gov/mpar-svmposium/2009/presentations/workshop/W2 Al- 
Rashid%2 0 Architecture .pdf . 

Army Force Management School. 2011. The Planning, Programming, Budgeting and 
Execution System: An Executive Primer. Accessed August 2013. 
https://www.documentcloud.org/documents/293931-DODarmvppbeprimemov- 
2011.html. 


Aspin, Les. 1993. Report on the Bottom Up Review. United States Department of 
Defense, Washington, DC. Accessed June 2013. 

http://www.DOD.mil/pubs/foi/administration and Management/other/515.pdf. 

Blanchard, Benjamin, and Wolter Fabrycky. 1998. Systems Engineering and Analysis, 3 nl 
Edition. Upper Saddle River, NJ: Prentice-Hall Inc. 

Charette, Robert M. 2008. “What’s Wrong with Weapons Acquisitions?” IEEE 
Spectrum. Accessed June 2013. http://www.ieee.org/index.html. 

Clark, Vern. 2002. “SeaPower 21: Projecting Decisive Joint Capabilities.” Accessed July 
2013. http://www.navv.mil/navvdata/cno/proceedings.html. 

Congressional Budget Office. 2003. Transforming the Navy’s Surface Combatant Force. 
Congress of the United States, Congressional Budget Office, Washington, DC. 

-. 2013. Approaches for Scaling Back the Defense Department’s Budget Plans. 

Congress of the United States, Washington, DC. Accessed May 2013. 
www.cbo.gov . 

Dalton, John, J.M. Boorda and Carl Mundy. 1994. Forward...From the Sea. Department 
of the Navy, Washington, DC. Accessed June 2013. 
http://www.dtic.mil/iv2010/navv/b014.pdf . 

Deegan, Chris. 2012. “ASNE.” Presentation delivered at the American Society of Naval 
Engineers “ASNE Day 2012—Naval Warfare—Critical Engineering Challenges.” 
9-10 February, Arlington, VA. 


107 



Defense Acquisition University. 2010. Introduction to Defense Acquisition Management, 
10th Edition. Fort Belvoir, VA: Defense Acquisition University Press. 


-. 2011. Program Manager’s Toolkit, 16th edition. Fort Belvoir, VA: Defense 

Acquisition University Press. The “horse blanket” chart can be accessed at 
https://ilc.dau.mil/ . 

-. 2013. Defense Acquisition Guidebook. Fort Belvoir, VA: Defense Acquisition 

University Press. 

Defense Industry Daily. 2013. The USA’s DDG-1000 Zumwalt Class Program: Dead 
Aim, or Dead End? Accessed June 2013. 

http://www.defenseindustrvdailv.com/dead-aim-or-dead-end-the-usas-ddglOOO- 

zumwalt-class-program-02574/ . 

Department of Defense Systems Management College. 2001. Systems Engineering 
Fundamentals. Fort Belvoir, VA: Defense Acquisition University Press. 

Elm, Joseph P., and Dennis R. Goldenson. 2012. The Business Case for Systems 

Engineering Study: Results of the Systems Engineering Effectiveness Surx’ey. A 
Special Report from the Carnegie Mellon University Software Engineering 
Institute. Published by the Software Engineering Institute Executive Agent, 
Hanscom AFB: Waltham, MA. 

Emery, Kathy. 2010. “Surface Navy Combat Systems Engineering Strategy.” 

Presentation to the Wayne E. Meyer Institute of Systems Engineering and 
Analysis, Naval Postgraduate School, Monterey CA. Accessed July 2013. 
http://www.nps.edu/Academics/Institutes/Mever/docs/IWS%20QA%20Briefing% 
20to%20NPS%20March0410.pdf. 

Fabey, Michael. 2013. “U.S. Navy Seeks Alternate Deckhouse for DDG-1002.” 
Aerospace Daily and Defense Report. Posted 25 January 2013. 
http ://www .military, com/ daily-news/2013/01/25/us-navy-seeks-altemate- 
deckhouse-for-ddg-1002 .html. 

Flood, Scott, and Paul Richard. 2005. “An Assessment of the Lead System Integrator 

Concept as Applied to the Future Combat System Program.” Defense Acquisition 
Review Journal, Dec 2005-Mar 2006. Army Test & Evaluation Command, 
Aberdeen Proving Ground, MD. Accessed July 2013. http://www.dtic.mil/cgi- 
bin/GetTRDoc?AD=AD A487783. 

Fox, J. Ronald, with contributions by David G. Allen, Thomas C. Lassman, Walton S. 

Moody, and Philip L. Shiman. 2011. Defense Acquisition Reform, 1960-2009: An 
Elusive Goal. Washington, DC: Center of Military History, United States Army. 

Friedman, Norman. 2006. The Naval Institute Guide to World Naval Weapon Systems, 

5th Edition. Annapolis, MD: Naval Institute Press. 

108 



Gansler, Jacques S., William Lucyshyn and Adam Spiers. 2009. “The Role of Lead 

System Integrator.” Presentation to the Naval Postgraduate School Acquisition 
Research Symposium, Monterey CA, 14 May. Accessed July 2013. 
https://calhoun.nps.edu/public/bitstreani/handle/10945/33376/NPS-AM-09- 
027.pdf?sequence=l. 

Goldberg, Sam. 2006. “How Things Work: The SBX Radar.” Air & Space Magazine. 
Accessed July 2013. http://www.airspacemag.com/how-things-work/phased- 
array-radar.html . 

Government Accountability Office. 2004. Challenges Facing the DD(X) Destroyer 

Program. GAO Report 04-973. Congress of the United States, Washington DC. 
Downloaded May 2013 from www.gao.gov/cgi-bin/getrpt?GAQ-04-973 . 

-. 2007. Defense Acquisitions: Role of Lead Systems Integrator on Future Combat 

Systems Program Poses Oversight Challenges. GAO Report 07-380, Office of 
the Comptroller General of the United States, Washington, DC. Downloaded June 
2013 from http://www.gao.gov/products. 

-. 2009. Defense Acquisitions: Report on Selected Acquisition Programs. GAO 

Report 09-326SP, Office of the Comptroller General of the United States, 
Washington, DC. Accessed May 2013. http://www.gap.gov/products/GAQ-09- 
326SP . 

-. 2013. Defense Acquisitions: Assessments of Selected Weapons Programs. GAO 

Report 13-294SP, Office of the Comptroller General of the United States, 
Washington DC. Accessed May 2013. http://www.gao.gov/products. 

Gully, John. 2003. “Future Combat System: Lead System Integrator.” Presentation for 
the National Defense Industrial Association, 12 February. Accessed June 2013. 
http://www.dtic.mil/ndia/2003munitions/gullv.pdf . 

Hagerty, James C., Pauleen D. Stevens and Bryan T. Wolfe. 2008. DDG 1000 vs. DDG 
51: An Analysis ofU.S. Navy Destroyer Procurement. MBA Report, Naval 
Postgraduate School, Monterey, CA. 

Hamey, Robert. 2005. Combat Systems Volume II, Part 11: Sensor Technologies. 
Textbook for course SI4112, Combat Systems Engineering /, at the Naval 
Postgraduate School, Monterey, CA. 

Harvey, J.C. 2012. “Surface Force Material Readiness Improvements.” Memorandum for 
the Record issued 03 August 2012 from the Commander, U.S. Fleet Forces 
Command, Norfolk, VA. 

Hitchins, Derek. 2013. Putting Systems to Work. Accessed January 2013. 
www.hitchins.net. 


109 



Hyer, Scott A.; Jerald J. Johnston and Charles L. Roe. 1996. “Integration of the Evolved 
Seasparrow Missile into Ships of the NATO Seasparrow Consortium Navies.” 
Johns Hopkins Advanced Physics Laboratory Technical Digest, 17 (3). 

Jane’s Defense Weekly. 2012. “Briefing: Naval multi-function radar, a new active age,” 
(September). Downloaded July 2013 from http://www.janes.com/defence. 

Jenn, David. 2010. Microwave Devices and Radar, Lecture Notes Volume 4 version 6. 
Accessed July 2013. http://facultv.nps.edU/ienn/EC4610/VolIVv6.0.pdf . 

-. 2010. Microwave Devices and Radar, Lecture Notes Volume 3 version 6. 

Accessed July 2013. http://facultv.nps.edU/ienn/EC4610/VolIIIv6.0.pdf 

Kadish, Ronald. 2005. Defense Acquisition Performance Assessment: Executive 

Summary. Prepared for the Acting Deputy Undersecretary of Defense by the 
Assessment Panel of the Defense Acquisition Performance Assessment Project. 

Kime, Patricia. 2004. “Integrated Warfare Systems Office Consolidates Programs, Cuts 
Costs.” Sea Power, Navy League of the United States, Arlington VA. February 
2004. Accessed July 2013. http://www.navyleague.org/sea power/feb 04 20.php . 

Krygiel, Annette. 1999. Behind the Wizard’s Curtain: An Integration Environment for a 
System ofSytems. Washington, DC: Command and Control Research Program 
Publication Series, Office of the Secretary of Defense. 

Langford, Gary. 2012. Engineering Systems Integration: Theory, Metrics and Methods. 
Boca Raton, FL: CRC Press. 

LaPointe, Kevin. 2013. “Status Briefing: SEA21A, Surface Warfare Directorate-Fleet 
Readiness.” Accessed July 2013. 

http://www.portengineerprogram.org/Conference Presentations/201 l/sea21 a.pdf. 

Liszniansky, Myron, and Tom Laliberty. 2006. “DDG 1000-First of the Zumwalt Class: 
Transforming the Navy.” Presentation to the Systems & Software Technology 
Conference, April 2006, Long Beach CA. 

Lockheed Martin Corporation. “Lockheed Martin Demonstrated New Radar Capabilities, 
Marks Radar Day.” Accessed May 2013. 
http://www.lockheedmartin.com/us/news/press- 
releases/2003/mav/LockheedMartinDemonstratesNewRadar C.html. 

Madni, Azad, and Michael Servers. 2012. “Systems Integration: Key Perspectives, 
Experiences, and Challenges.” Posted 29 September 2012 in Systems 
Engineering, www.wileylibraryonline . 


110 



Metz, Steven, and James Kievit. 1995. Strategy and the Revolution in Military Affairs: 

From Theory to Policy. Carlisle Barracks, PA: U.S. Army War College Strategic 
Studies Institute. 

Miller, Michael, and Robert E. Gray. 2012. “The Wrong Debate.” Proceedings 138 (2). 

Mink, Jesse M. 2006. Analysis of Horizontal Integration within the Program Executive 
Office, Integrated Warfare Systems. Master’s thesis, Naval Postgraduate School, 
Monterey CA. 

National Aeronautics and Space Administration (NASA). 2007. Systems Engineering 

Handbook. Hanover, MD: NASA Scientific and Technical Information Program. 

National Defense Industrial Association, Systems Engineering Division Task Group 
Report. 2003. The Top Five Systems Engineering Issues in Defense Industry. 
Accessed May 2013. 

http://www.aticourses.com/sampler/TopFiveSvstemsEngineeringIssues In Defen 
selndustry.pdf 

Naval Education and Training Command. 2000. Fire Controlman Volume II: Fire 
Control Radar Fundamentals. Pensacola, FL: Naval Education and Training 
Command, Nonresident Training Course NAVEDTRA 14099. 

O’Donnell, Robert. 2013. “Radar Systems Engineering.” An online engineering course 
sponsored by the Institute of Electrical and Electronics Engineers (IEEE)-New 
Hampshire Section, the IEEE Aerospace and Electronic Systems Society (AESS), 
and the MIT Lincoln Laboratory. Accessed June 2013. 
http://aess.cs.unh.edu/radar%20se%20List%20ofi/o20Lectures%20.html. 

Office of the Assistant Secretary of Defense for Public Affairs. “Navy Briefing on DD(X) 
Down-select Decision.” Transcript of remarks by Assistant Secretary of the Navy 
John Young delivered 22 April 2002. Accessed July 2013. 
http://www.defense.gov/Transcripts/Transcript.aspx?TranscriptID=3421. 

Office of the Deputy Assistant Secretary of Defense for Systems Engineering. “Systems 
Engineering Homepage.” Accessed July 2013. 
http://www.acq.osd.mil/sc/index.html. 

Office of the Secretary of Defense. 2001. 2001 Quadrennial Defense Review. United 
States Department of Defense, Washington, DC. Downloaded June 2013 from 
http://www.defense.gov/pubs/qdr2001 .pdf. 

-. 2010. 2010 Quadrennial Defense Review. United States Department of Defense, 

Washington, DC. Accessed June 2013. 

http://www.defense.gov/qdr/images/QDR as of 12FeblO 1000.pdf 


111 








O’Rourke, Ronald. 28 October 2004. Navy DD(X) Destroyer Program: Background and 
Issues for Congress. Congressional Research Service, Washington, DC. 

-. 5 June 2008. Navy DDG-1000 Destroyer Program: Background, Oversight 

Issues, and Options for Congress. Congressional Research Service, Washington, 
DC. 

-. 18 October 2012. Navy DDG-51 and DDG-1000 Destroyer Programs: 

Background and Issues for Congress. Congressional Research Service, 
Washington, DC. 

-. 27 March 2013. Navy DDG-51 and DDG-1000 Destroyer Programs: 

Background and Issues for Congress. Congressional Research Service, 
Washington, DC. 

Owens, Mackubin T. 2013. “La Petite Guerre: A Review of Max Boot’s Invisible 
Armies .” National Review, Vol. 65 No. 2(11 February). 

Program Executive Office, Integrated Warfare Systems, Surface Ship Weapons. 2012. 
DDG 1000 Requirements Gap Assessment. From the author’s working files. 

Rand Corporation National Defense Research Institute. 2011a. Root Cause Analyses of 
Nunn-McCurdy Breaches, Volume I: Zumwalt-class Destroyer, Joint Strike 
Fighter, Longbow Apache, and Wideband Globed Satellite. Santa Monica, CA: 
The Rand Corporation. 

-. 2011b. Learning From Experience, Volume II: Lessons from the U.S. Navy’s 

Ohio, Seawolf, and Virginia Submarine Programs. Santa Monica, CA: The Rand 
Corporation. 

Raytheon Corporation. 2013. “Zumwalt Class Destroyer Critical Technologies.” 
Accessed June 2013. 

http://www.raytheon.com/capabifities/products/zumwalt/tech/index.html. 

Roughead, Gary, James Conway, and Thad Allen. 2007. A Cooperative Strategy for 21 st 
Century Seapower. Washington, DC: Department of the Navy. 

Skolnick, Merrill. 2008. Radar Handbook: 3 ld Edition. New York, NY: McGraw-Hill 
Companies. Accessed July 2013. 

http://accessengineeringlibrarv.com/browse/radar-handbook-third- 

edition#fullDetails . 

Stuckenbruck, L. C. 2008. “Integration: The Essential Function of Project Management,” 
in Project Management Handbook, Second Edition (eds D. I. Cleland and W. R. 
King). Hoboken, NJ: John Wiley & Sons, Inc. doi: 10.1002/9780470172353.ch3 


112 



Syring, James. 2012. “Program Executive Office Integrated Warfare Systems.” Briefing 
delivered to the Surface Navy Association Symposium, 10 January. Accessed July 
2013. 



Thales Corporation. 2013. “APAR Active Phased Array Multi-function Radar.” Accessed 
June 2013. www.thalesgroup.com/apar. 

United States Navy. 2012a. “Evolved SeaSparrow Fact File.” Updated 19 November 
2013. http://www.navv.mil/navvdata/fact.asp. 

-. 2012b. “Standard Missile Fact File.” Updated 15 November 2013. 

http://www.navv.mil/navydata/fact.asp. 

-. 2012c. “Aegis System Fact File.” Updated 22 November 2013. 

http://www.navv.mil/navvdata/fact.asp. 

Welby, Stephen. 2013. “OSD Systems Engineering Status and Goals,” presentation to the 
National Defense Industrial Association Systems Engineering Meeting, February 
2013. 

Welch, Shawn. 2007. Joint and Interdependent Requirements: A Case Study in Solving 

the Naval Surface Fire Support Capabilities Gap. Norfolk, VA: Joint Forces Staff 
College. Accessed June 2013. http://www.dtic.mil/cgi- 
bin/GetTRDoc?AD=ADA481976. 


White, J., and Amy Billups. “Navy Radar Trades at the Ship Interface.” Accessed 
September 2013. 

https://www.navalengineers.org/SiteCollectionDocuments/2008%20Proceedings 

%20Documents/ASNE%20Day%202008/paper6.pdf. 

Winter, Donald C. 2006. Remarks to the Navy League Sea-Air-Space Exposition. 

Remarks made 4 April 2006 to the Navy Feague Exposition, Washington, DC. 
Accessed July 2013. 

http://www.navv.mil/navvdata/people/secnav/winter/2006USNF SeaAirSpaceEx 
position.pdf. 

Zumwalt Program Office. 2013. “DDG-1000 Class Destroyer: Overview.” Presentation 
to the Sea Air and Space Symposium, April 2013. Accessed June 2013. 
http://www.navsea.navv.mi1/Media/SAS2013/l.%20DDG%201000.pdf. 


113 



THIS PAGE INTENTIONALLY LEFT BLANK 


114 



INITIAL DISTRIBUTION LIST 


1. Defense Technical Infonnation Center 
Ft. Belvoir, Virginia 

2. Dudley Knox Library 
Naval Postgraduate School 
Monterey, California 


115 



